Bitcoin Forum
December 11, 2016, 06:20:57 AM *
News: Latest stable version of Bitcoin Core: 0.13.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 ... 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 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1808486 times)
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
July 15, 2015, 12:22:50 AM
 #28801

I suspect we agree that should 1MB blocks become an undeniably urgent concern (EG, if we see actual congestion resulting in appropriate fees no longer prioritizing their tx) the controversy will rapidly dissipate and be replaced by emergent rough consensus.

I do not understand why do we need to increase block size if we want to "employ minfee".
Let's try to "employ minfee" and if they raise too high then we will increase block size to reduce them.

It is clear that the people here are not so far apart after all. In reality it is differences of opinion on how to reach similar goals.

What is highlighted above would be fine if we were talking about a traditional centralized system, where a few people have control of all the software instances. Of course it would be possible to wait until there is actual tx congestion or fees tracking too high, unwise maybe, but very do-able, because it would be relatively quick to upgrade and continue as before.

With a decentralized system this is a luxury which does not exist, because the many instances within it are controlled by different people with different priorities, situations, political constraints, and speak different languages. A change that affects all of them needs to be given as much time as possible to be implemented.

Ideally, Satoshi should have listened to Jeff Garzik and caveden and implemented a flexible cap with his 1MB change in 2010. Done 5 years ago, the hard-fork would be a big fat nothing event as close to 100% of the full nodes in Bitcoin's network would be upgraded before the first >1MB block. If the change was done early in 2013, when the matter was heavily discussed, it would have given a 2-year delay before activation, so perhaps 95% of the full nodes would be upgraded. This is what BIP 100 assumes is still possible, but the 1Mb has become politicized so 95% is unlikely to be achievable and a rogue miner with 6% of the hash-rate could cripple Bitcoin long-term. So Gavin's BIP 101 assumes a 75% threshold, plus a grace period to help boost numbers. This is much more realistic but a rough hard-fork is now inevitable. The worst option is to wait until the change is obviously needed and try to do what Greg thinks is easy: a 2-week hard-fork. This might be easy for Core Dev gurus, but for thousands of full nodes this will come as a major shock, maybe leaving 50% of the nodes on each fork for a while. A "battle of the forks" might be an interesting and amusing real-world scenario test for cryptogeeks, but for 99% of Bitcoiners this would be a nightmare, they would be scared about the fate of their BTC, it would cause a serious loss of faith in this paradigm of new money.

Being preemptive about the 1MB reminds me of the Y2K situation. I spent a large chunk of 1998 on this as our company had 600 programs to change (requiring individual review) in just one sub-system, which also had 20 million abbreviated dates in the db and datafiles (requiring synchronized conversion with the programs), many of which existed from the 1980s when storage of all types was at a premium. The amount of testing required was laborious. Without this work the sub-system would have failed on Jan 1st 2000 costing the company tens of millions and making the name of the IT division "useless scum" in the minds of all the users. This was a centralized instance of software under the control of a handful of people. Even then the change was done over 1 year in advance of the Y2K date, and worked beautifully on the day.

TL:DR
If a software change needs 6 months or a year to happen then get it in progress 6 months or a year before it is needed by the user-base.


1481437257
Hero Member
*
Offline Offline

Posts: 1481437257

View Profile Personal Message (Offline)

Ignore
1481437257
Reply with quote  #2

1481437257
Report to moderator
1481437257
Hero Member
*
Offline Offline

Posts: 1481437257

View Profile Personal Message (Offline)

Ignore
1481437257
Reply with quote  #2

1481437257
Report to moderator
1481437257
Hero Member
*
Offline Offline

Posts: 1481437257

View Profile Personal Message (Offline)

Ignore
1481437257
Reply with quote  #2

1481437257
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481437257
Hero Member
*
Offline Offline

Posts: 1481437257

View Profile Personal Message (Offline)

Ignore
1481437257
Reply with quote  #2

1481437257
Report to moderator
1481437257
Hero Member
*
Offline Offline

Posts: 1481437257

View Profile Personal Message (Offline)

Ignore
1481437257
Reply with quote  #2

1481437257
Report to moderator
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1512


Crypto is the separation of Power and State.


View Profile WWW
July 15, 2015, 12:27:44 AM
 #28802

TX fees are still orders of magnitude below their cost in electricity, etc., demonstrating fee pressure insufficient for develop mature markets.


I had forgotten this gem.  Roll Eyes  Fortunately your personal opinions don't matter; this is not a centrally planned economy.

You should take more care in committing to memory my gems of wisdom.   Wink

Are you asserting that (contrary to my "personal opinion") TX fees are *not* orders of magnitude below their cost in electricity, etc.?

Are you likewise asserting current fee pressure is sufficient to develop mature markets?

Please provide citations/evidence for your gainsaying.


I suspect we agree that should 1MB blocks become an undeniably urgent concern (EG, if we see actual congestion resulting in appropriate fees no longer prioritizing their tx) the controversy will rapidly dissipate and be replaced by emergent rough consensus.

And I guess we will have to ask you if the fees are "appropriate" or not.

Nope.  In that context "appropriate" means "competitive."  We simply have to watch and see if tx with appropriately competitive (as objectively defined by current fee context) are given the priority for which they have paid.

If you could actually respond to what I write, instead of deflecting by characterizing it as subjective, that would be great.   Smiley

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
Fungibility provides privacy as a side effect.  Adam Back 2014
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Wallets - Podcats - Roadmap - Dice - Blackjack - Github - Android }


Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


"I believed @Dashpay instamine was a bug & not a feature but then read: https://bitcointalk.org/index.php?topic=421615.msg13017231#msg13017231
I'm not against people making money, but can't support questionable origins."
https://twitter.com/Tone_LLT/status/717822927908024320


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004

"Hard forks cannot be co
Adrian-x
Legendary
*
Offline Offline

Activity: 1330



View Profile
July 15, 2015, 01:22:57 AM
 #28803


The block size limit is a short term hack.  Someday we might get beyond such a limit, but it could be quite a while.  BIP100 looks promising though.

"a short term hack" is how I see it, what concerns me is developers appear to be leveraging it to push through other hacks. (hacking the hack - postponing indefinably until such time as other hard fork changes could be bundled in with this one.)

BIP100 is good in that it removes the hard fork limit, my reservations though are that it does nothing to erode the centralized control system that has evolved. I prefer Bib 101 as it implies some central gate keepers need to eat humble pie, however nether are my first choice.  

At this stage I'd like to start seeing more decentralized development, the notion that Bitcoin is resilient in that if the protocol is modified the ideals will never be eroded because it is open source and can be forked to keep the original intent appears to only be valid so long as we share the same motives as the centralized development team.

The very idea of forking that was originally proposed to protect Bitcoin Values was vehemently opposed by the centralized developers who expressed disdain that they were not consulted and their process for seeking permission to propose change was not adhere too, even going so far as calling the idea of forking to remove the hard limit a threat to the very success of bitcoin.

I think there is a distortion of perception and lack of empathy all round. ultimately it is the people who put economic energy into the idea that make it viable, and while developers are all important, they are not the gods who conduct this experiment, its the people who put in there economic energy.    

Your reasoning is interesting to me.  Mostly because your evaluation appears to contradict your conclusion.  And so, I suspect you have a some well thought out ideas and nuances that you've not yet communicated.

Both 100 and 101 provide a mechanism for more block size.  Choosing between the two may depend on your perspectives and assessment of different risk levels within the operating groups.

Do you see more centralized control among developers or miners?
- If development is more centralized, BIP100, (developers giving controls to miners).
- If mining is more centralized, BIP101, (developers retaining control over block size increases and schedules).

Both remain fairly centralized, though both are less so than they previously have been.  From your discourse, it would seem your evaluation would be the devs are more centralized and so would favor BIP100, (irrespective of who authored it).

I'm not sure I see the contradiction, my understanding is based on the situation we have now and it's a typical political one.

The moment we started to see mining pools and solo miners contributing hashing power with little regard to hard forks is when this trajectory started, I cant remember what the BIP was back in 2011/2, where miners had to choose which fork to support, back then I didn't care as it was the fundamentals that were important to me and that wasn't considered one given my limited understanding back then.  ( i just supported my "political mining pool by giving them my vote" to use as they saw fit.)

anyway I think all developers need a reason to develop and I'm happy with the idea that some will be commercial, however developers are just developing the code that runs the protocol. The people that invest in Bitcoin invest because they understand the incentive structure that makes the protocol possible.

Bitcoin is more about the network of current users than it is about the code, changing the code and protocol to appeal to old world industrious is not how we should be working, we want them to change to adopt Bitcoin.

I may be underestimating the concerns with centralized mining but I dont see it as an issue, miners will always mine the bitcoin that has the most users, and that typically is misunderstood as the most nodes, so long as miners do not have a say in changing the incentives in the protocol I see no problems moving forward with larger blocks. (Blockstream have crossed this line)

I am concerned that development is very centralized just a handful of people determine the code that runs on almost 99% of nodes, I favor many implementation of the code, not just Core, so in my view BIP100 and BIP101 are a political compromise to keep centralized development in the hands of a few.

BIP100 essentially takes the block size it out of the hands of developers and gives it to the miners.  They will decide if it grows or not.
BIP101 keeps block size as a centrally managed resource, pre-determined by developers, and if modification up or down is needed, it would need to be done by developers.

The weighting of your discussion suggests the developer centralization is a more serious concern, which suggests that BIP100 would be a strong favorite for you.

Personally I like BIP100 more also just because it does not have the hubris to attempt to predict what future changes to block size may be best suited for the protocol, and leaves those decisions to the future folks who will know better than we could possibly do now.
I also like that it decentralizes the management of the decision to the miners, which to me is a fine place for it.

That you favored BIP101 was the surprising part for me, I don't see why that would be the case considering your concerns.

you put it all so distinctly I enjoy the time you take to simplify your thoughts and you have my motives pity much pined.  

I agree with the sentiment in bold, however as I understand BIP100 doesn't decentralize the management of block size it puts it in the control of the majority of miners, miners in the future could be having this same debate but in the context of market imbalances, political pressure or geographical restraints that could serve to pit one group of miners against the another.

The majority of miners may choose to limit block size because they have slow internet - or because some for profit company will facilitate or offer additional revenue through Merge Mine SideChains if they agree to limit block size to force transactions off chain (they could even earn more revenue than competing for the same transactions on Bitcoin transactions)  

I think the best outcome is for the full diversity in economic imbalances to play out in mining, and miners find the balance in the economiccs of risks and benefits of whatever gives them a competitive advantage, but they need to compete in a free market space free of coercion.  

In effect miners should have 100% autonomy in the size of the blocks they produce, the majority of miners should not have the ability to collude. As I see it BIP100 would allow the majority of miners to set the block size, where in fact I want the incentives to encourage all miners to make small blocks but without limit should they feel it would be more competitive.

miners in my view are the most marginalized group in bitcoin, they are condemned to eek out the smallest viable profit on top of the cost of the utility of securing the network and the transactions in it, as block rewards diminish, this is by design.

This feature is not widely discussed but ultimately its an environmental concern, in the most fantastic of outcomes, it comes down to how much of the earth resources should be invested in securing the money supply, and the answer that makes the most sense is the minimum necessary to ensure its integrity, most other schemes in fact all iterations that I've cared to explore are less efficient from and environmental impact perspective, than storing secured transactions on the block-chain. that dosent mean there is no need for LN or SC, or other variants but they need to compete in a free market not a planed one.  

BIP101, is not ideal, I'd rather have no limit, but it seemed the limit could grow faster than the Bitcoin network grows. and I like the fact that "eight" (八 Pinyin: bā) sounds similar to the word which means "wealth" in Chinese, and we have eight doubling so it should be appalling to those who are governed by superstition.  
  

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1512


Crypto is the separation of Power and State.


View Profile WWW
July 15, 2015, 01:51:11 AM
 #28804

I suspect we agree that should 1MB blocks become an undeniably urgent concern (EG, if we see actual congestion resulting in appropriate fees no longer prioritizing their tx) the controversy will rapidly dissipate and be replaced by emergent rough consensus.

I do not understand why do we need to increase block size if we want to "employ minfee".
Let's try to "employ minfee" and if they raise too high then we will increase block size to reduce them.

It is clear that the people here are not so far apart after all. In reality it is differences of opinion on how to reach similar goals.

Are you trying to be reasonable?  You realize this is bitcointalk, and Frap.doc's goldbug trolling thread to boot, right?   Cheesy

Seriously though, I think we are seeing divergence in not only methods but also goals between the RetailCoffeeCoiners and SettlementBackboneCoiners (with Frap.doc's AllThingsToAllPeopleAtAllTimesCoiners being the worst of all).

Ideally, Satoshi should have listened to Jeff Garzik and caveden and implemented a flexible cap with his 1MB change in 2010. Done 5 years ago, the hard-fork would be a big fat nothing event as close to 100% of the full nodes in Bitcoin's network would be upgraded before the first >1MB block. If the change was done early in 2013, when the matter was heavily discussed, it would have given a 2-year delay before activation, so perhaps 95% of the full nodes would be upgraded.

I disagree with your application and the propriety of 20/20 hindsight.  We did have a "flexible cap" but it was soft, not hard.

Without that, it's less likely the devs could have (so relatively smoothly) scaled and optimized Bitcoin all the way up to coping with full 1MB blocks, which was a very challenging albeit under-appreciated task.  Even so and as mostly notably reported by gmax, Bitcoin's decentralization/trustlessness has by some important metrics suffered along the way.

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
Fungibility provides privacy as a side effect.  Adam Back 2014
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Wallets - Podcats - Roadmap - Dice - Blackjack - Github - Android }


Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


"I believed @Dashpay instamine was a bug & not a feature but then read: https://bitcointalk.org/index.php?topic=421615.msg13017231#msg13017231
I'm not against people making money, but can't support questionable origins."
https://twitter.com/Tone_LLT/status/717822927908024320


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004

"Hard forks cannot be co
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 15, 2015, 02:06:24 AM
 #28805

iCEBLow has been cooing on about a fiction fee market. His prime example just blew up:

http://www.reddit.com/r/Bitcoin/comments/3db7qr/mycelium_servers_down/
2112
Legendary
*
Offline Offline

Activity: 1708



View Profile
July 15, 2015, 03:07:03 AM
 #28806

BIP101, is not ideal, I'd rather have no limit, but it seemed the limit could grow faster than the Bitcoin network grows. and I like the fact that "eight" (八 Pinyin: bā) sounds similar to the word which means "wealth" in Chinese, and we have eight doubling so it should be appalling to those who are governed by superstition.  
Appalling or appealing? It is hard to tell if you are serious or sarcastic.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Zarathustra
Legendary
*
Offline Offline

Activity: 938


View Profile
July 15, 2015, 06:21:41 AM
 #28807

It is about a majority of brain cells and intellectual authority.
The value of money comes from future economic output.

The majority of entities that will produce the most economic value in the future is the majority that matters.

In many cases, people who have accumulated a large amount of money in the present have done so because they have a high capacity to produce economic value and so in their case they contribute significantly to the economic majority.

This is not true in all cases, however. Someone who obtained large amounts of money through luck or via processes which are not repeatable in the future don't contribute as much to the economic majority as their current holdings would suggest.

This is the primary flaw behind who try to frame debates in terms of "rich" vs "poor". They aren't being sufficiently precise.

Yes, but additional production is always produced via credit. A system without credit/debt does not need to grow and therefore it doesn't grow. Rain forest people are not forced to increase their 'output'. Their output does not grow in thousand years. Only nationalized people are forced to produce surplus, because they are forced to pay tribute. That's the root of credit/debt: organized violence (collectivism/society).

"Staat nenne ich's, wo alle Gifttrinker sind, Gute und Schlimme: Staat, wo alle sich selber verlieren, Gute und Schlimme:
Staat, wo der langsame Selbstmord aller – »das Leben« heisst."
smoothie
Legendary
*
Offline Offline

Activity: 1848


LEALANA Monero Physical Silver Coins


View Profile
July 15, 2015, 06:31:49 AM
 #28808

OK.  Provide me with your estimates for the following (and explain how you arrived at your numbers) and I'll update my table using your numbers:
1.  The cost per node to store 1 GB of additional blockchain data for 5 years, assume the outputs are spent.
2.  The cost per node to store 1 GB of additional blockchain data for 5 years, assuming the outputs are unspent.
I may be missing the context as this thread is high volume and I've not read any of the backlog...

But for a full verifying node, the on-going cost cost of 1GB of additional transactions with all outputs spent is 0; all the cost related to that 1GB of data is related to the bandwidth to get it to you and the verification cost, and for short term storage until its burried, after that it need not be stored.
The cost for unspent is some non-zero number which depends on your estimation of storage costs.

This thread can be hard to follow if you're not following it all the time!  

The question was in reference to a debate I was having with Odalv about these "order of magnitude" estimates shown in this table.  I was suggesting that, under the conditions considered in the table, it is cheaper for miners to write the spam to the Blockchain and more costly for the spammer, than continually rejecting it:



Does CreateNewBlock currently take longer to execute if there are more TXs in a miner's mempool to pick from?  If so, this would add credence to Cypherdoc's hunch that miner's are producing more empty blocks when mempool swells.  
Yep, I already pointed that out to you specifically! It's superlinear in the mempool size (well, ignoring caching)  But thats unrelated to f2pool/antpool and the other SPV miners, as they're not ever calling createnewblock in that case, as they're mining without even validating.   One can mine on a validated chain with no transactions while waiting for createnewblock (which is what eligius does, for example).  

Sorry, yes I know you explained that.  The point I'm trying to make is that if CreateNewBlock is super-linear in mempool size, then it would not be surprising to see more empty blocks (what Cypher was calling "defensive blocks") when mempool swells (the miners are mining on an empty block for longer while waiting for CreateNewBlock to finish).  This was Cypher's point from the very beginning that many people, including myself, were suggesting was probably not the case!  

Furthermore, how can f2pool/antpool mine a non-empty block without calling createnewblock?

So pretty much it is more costly to the spammer if miners just write the spam (or accept the tx) into the block chain.

Interesting.

Sorry, but this cannot be true. It is like perpetuum mobile. The bigger block the cheaper it is => let's are try 1 TB block => it must be free

spammers don't control size of blocks in a no limit scenario.  miners do.  so we won't have 1TB blocks b/c miners have the incentive to not destabilize or destroy the network so they will construct large enough blocks that are efficiently optimized so as to not get orphaned and not create significant decentralization of full nodes.  they will also raise their minfee to keep their mempool from destabilizing their full nodes and to keep users access open and readily accessible.  spammers will actually have to pay instead of just recycling their unwritten spam fees.

It makes sense to accept the spam transactions assuming it will cost the spammer more than to reject it and have them recycle the tx for those unwritten.

███████████████████████████████████████

            ,╓p@@███████@╗╖,           
        ,p████████████████████N,       
      d█████████████████████████b     
    d██████████████████████████████æ   
  ,████²█████████████████████████████, 
 ,█████  ╙████████████████████╨  █████y
 ██████    `████████████████`    ██████
║██████       Ñ███████████`      ███████
███████         ╩██████Ñ         ███████
███████    ▐▄     ²██╩     a▌    ███████
╢██████    ▐▓█▄          ▄█▓▌    ███████
 ██████    ▐▓▓▓▓▌,     ▄█▓▓▓▌    ██████─
           ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌          
           ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌          
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─  
     ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩    
        ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀       
           ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀`          
                   ²²²                 
███████████████████████████████████████

. ★☆ WWW.LEALANA.COM        My PGP fingerprint is A764D833.        SMOOTHIE'S HEALTH AND FITNESS JOURNAL          History of Monero development Visualization ★☆ .
LEALANA  PHYSICAL MONERO COINS 999 FINE SILVER.
 
smoothie
Legendary
*
Offline Offline

Activity: 1848


LEALANA Monero Physical Silver Coins


View Profile
July 15, 2015, 06:37:34 AM
 #28809

The 7-day moving average of the blocksize is now in the red zone--six months ahead of schedule.



Where can I gain access to this chart as it is updated?

███████████████████████████████████████

            ,╓p@@███████@╗╖,           
        ,p████████████████████N,       
      d█████████████████████████b     
    d██████████████████████████████æ   
  ,████²█████████████████████████████, 
 ,█████  ╙████████████████████╨  █████y
 ██████    `████████████████`    ██████
║██████       Ñ███████████`      ███████
███████         ╩██████Ñ         ███████
███████    ▐▄     ²██╩     a▌    ███████
╢██████    ▐▓█▄          ▄█▓▌    ███████
 ██████    ▐▓▓▓▓▌,     ▄█▓▓▓▌    ██████─
           ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌          
           ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌          
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─  
     ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩    
        ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀       
           ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀`          
                   ²²²                 
███████████████████████████████████████

. ★☆ WWW.LEALANA.COM        My PGP fingerprint is A764D833.        SMOOTHIE'S HEALTH AND FITNESS JOURNAL          History of Monero development Visualization ★☆ .
LEALANA  PHYSICAL MONERO COINS 999 FINE SILVER.
 
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
July 15, 2015, 06:40:23 AM
 #28810

The 7-day moving average of the blocksize is now in the red zone--six months ahead of schedule.



Where can I gain access to this chart as it is updated?

You'd have to hack my laptop Cheesy  Actually, just post a request here or PM me and I'll try to upload an updated version.  I use the 7-day moving average, so it responds slow to changes.    

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
smoothie
Legendary
*
Offline Offline

Activity: 1848


LEALANA Monero Physical Silver Coins


View Profile
July 15, 2015, 06:46:23 AM
 #28811

The 7-day moving average of the blocksize is now in the red zone--six months ahead of schedule.



Where can I gain access to this chart as it is updated?

You'd have to hack my laptop Cheesy  Actually, just post a request here or PM me and I'll try to upload an updated version.  I use the 7-day moving average, so it responds slow to changes.    

Got it.  Wink Will make a request.

███████████████████████████████████████

            ,╓p@@███████@╗╖,           
        ,p████████████████████N,       
      d█████████████████████████b     
    d██████████████████████████████æ   
  ,████²█████████████████████████████, 
 ,█████  ╙████████████████████╨  █████y
 ██████    `████████████████`    ██████
║██████       Ñ███████████`      ███████
███████         ╩██████Ñ         ███████
███████    ▐▄     ²██╩     a▌    ███████
╢██████    ▐▓█▄          ▄█▓▌    ███████
 ██████    ▐▓▓▓▓▌,     ▄█▓▓▓▌    ██████─
           ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌          
           ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌          
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─  
     ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩    
        ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀       
           ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀`          
                   ²²²                 
███████████████████████████████████████

. ★☆ WWW.LEALANA.COM        My PGP fingerprint is A764D833.        SMOOTHIE'S HEALTH AND FITNESS JOURNAL          History of Monero development Visualization ★☆ .
LEALANA  PHYSICAL MONERO COINS 999 FINE SILVER.
 
BldSwtTrs
Legendary
*
Offline Offline

Activity: 808


View Profile
July 15, 2015, 09:11:08 AM
 #28812

Yes, but additional production is always produced via credit. A system without credit/debt does not need to grow and therefore it doesn't grow. Rain forest people are not forced to increase their 'output'. Their output does not grow in thousand years. Only nationalized people are forced to produce surplus, because they are forced to pay tribute. That's the root of credit/debt: organized violence (collectivism/society).
I am sorry but that's some weird, utterly false statements.

If I am owner of my production I will produce beyond my consumption needs (that's called capital accumulation) to improve my standard of living in the future, even if I have no debt. The capital accumulation will enhance my productivity and thus allow me to produce more output.

The output of rain forest people doesn't grow because their culture haven't evolved private property rules, it is no related to debt.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 15, 2015, 12:06:00 PM
 #28813

Now, for the first time ever, people are starting to have to think about abandoning Mycelium, probably the most popular android wallet,  because core dev refuses to address the spam attack with bigger blocks.

Great job ICBLow!
brg444
Hero Member
*****
Offline Offline

Activity: 630

Bitcoin replaces central, not commercial, banks


View Profile
July 15, 2015, 12:27:10 PM
 #28814

Now, for the first time ever, people are starting to have to think about abandoning Mycelium, probably the most popular android wallet,  because core dev refuses to address the spam attack with bigger blocks.

Great job ICBLow!

Will you please spare us your brainless FUD?

This is why people cannot take you seriously.

Mycelium fucked up. That's all there is to it.

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
July 15, 2015, 12:59:50 PM
 #28815

The output of rain forest people doesn't grow because their culture haven't evolved private property rules, it is no related to debt.
There are a few prerequisites needed before people can start producing economic surplus.

Tribal people in rain forests haven't yet figured out how to not routinely murder each other, so learning how to not respect property is still a ways off.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 15, 2015, 03:36:35 PM
 #28816

here's Tom Harding's reply on bitcoin-dev to the double spends being inflicted on the 0confs in the bloated mempools as a result of the full blocks.

https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00500.html:

On Wed, Jul 15, 2015 at 07:35:21AM -0700, Tom Harding via bitcoin-dev wrote:
>
> You perform a valuable service with your demonstration, but you
> neglected to include the txid's to show that you actually did it.
 
> Your advice is must-follow for anyone relying on an unconfirmed tx: it
> must pay a good fee and be highly relayable/minable.

Actually, I was looking at what I believe was (part of?) this attack
yesterday in the logs on my full-RBF nodes and the txs involved *did*
have good fees and were highly relayable/minable
- the double-spent txs
had near 100% propagation on blockchain.info (who has unfortunately
purged the relevant data already)

Shapeshift.io depends on Blockcypher's "confidence factor" model(1)
under the hood - yet another one of those sybil attacking network
monitoring things - to estimate tx confirmation probability by looking
at the % of nodes a tx has propagated too. But miners frequently use
customized Bitcoin Core codebases that don't follow normal policies, so
those measurements don't actually tell you what you need to know.

hapeshift confirmed(2) the attack - confirming that they disabled
unconfirmed tx acceptance - said they're going to "improve" their
system... It'll be interesting to see what that actually entails.

1) https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
2) https://www.reddit.com/r/Bitcoin/comments/3ddkhy/bitcoindev_significant_losses_by_doublespending/ct468p7

-- 'peter'[:-1]@petertodd.org 000000000000000010bf087ed645cba129e2523930d5cde636ddbae9e03aef9c
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 15, 2015, 03:39:27 PM
 #28817

Now, for the first time ever, people are starting to have to think about abandoning Mycelium, probably the most popular android wallet,  because core dev refuses to address the spam attack with bigger blocks.

Great job ICBLow!

Will you please spare us your brainless FUD?

This is why people cannot take you seriously.

Mycelium fucked up. That's all there is to it.

it's idiots like you that will get Bitcoin into trouble.  i can't help you if you don't understand the technicals behind what is going on.  bigger blocks would allow clearing of the mempool:

https://www.reddit.com/r/Bitcoin/comments/3db7qr/mycelium_servers_down/ct3mbjj
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 15, 2015, 03:40:08 PM
 #28818

oh.

Gold collapsing.  Bitcoin UP.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 15, 2015, 03:41:40 PM
 #28819

here's Gavin this morning on dynamic block size:

@flix1 : dynamic limits are harder to implement-- I volunteered to help @jgarzik implement BIP100, and when diving into actually coding it up, the combination of headers-first and out-of-order block fetching makes any dynamic limit based on previous block sizes or votes in coinbase transactions non-trivial because the max block size may not be known when the block data is received.

That's not a show-stopper problem: a 'maximum feasible block size' could be used for initial denial-of-service checks on 'block' message size based on the block height, with a tighter check on size done when all previous blocks have been downloaded and validated and the block is added to the chain.

But it is much simpler if the max size is a pure function based on data in the block header.


Reply to this email directly or view it on GitHub.
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1512


Crypto is the separation of Power and State.


View Profile WWW
July 15, 2015, 03:44:58 PM
 #28820

Now, for the first time ever, people are starting to have to think about abandoning Mycelium, probably the most popular android wallet,  because core dev refuses to address the spam attack with bigger blocks.

Great job ICBLow!

Will you please spare us your brainless FUD?

This is why people cannot take you seriously.

Mycelium fucked up. That's all there is to it.

Have mercy on poor befuddled old Frap.doc.

So paltry is his understanding of Bitcoin technology, he believes Mycelium's issues in some way supervene upon Bitcoin itself!

So great is his ignorance of Bitcoin affairs, he fails to notice core devs addressing the spam attack on several fronts, including community reach-out to educate on best practices, code improvements/optimizations, and BIP submissions addressing his beloved 'bigger blocks.'

We should feel sorry for him, instead of committing cruelty to dumb animals.

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
Fungibility provides privacy as a side effect.  Adam Back 2014
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Wallets - Podcats - Roadmap - Dice - Blackjack - Github - Android }


Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


"I believed @Dashpay instamine was a bug & not a feature but then read: https://bitcointalk.org/index.php?topic=421615.msg13017231#msg13017231
I'm not against people making money, but can't support questionable origins."
https://twitter.com/Tone_LLT/status/717822927908024320


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004

"Hard forks cannot be co
Pages: « 1 ... 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 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 ... 1560 »
  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!