Topic: Gold collapsing. Bitcoin UP. - page 86. (Read 2032247 times)

i think this proves that miners are perfectly capable of handling bigger blocks as evidenced by the "no delays" in confirmation intervals.  if anything i find it interesting that they get sped up to <10 min during these attacks.  with bigger blocks, we'd clear out that mempool in an instant:

This is a disaster.

On the one hand, we have a person who's actually telling the truth and also is the same guy who tried to break Tor, add blacklists, and other assorted nasty features.

On the other hand we have someone who tends to invent legitimately useful things, and also lie when it suits his purposes.



There's nothing worse than having to agree with the turd sandwich, because he's the only one telling the truth.

talk about getting rekt.  Gregcoin my ass.

from Mike Hearn:

   >It was _well_ .... understood that the users of Bitcoin would wish to protect its decenteralization by limiting the size of the chain to keep it verifyable on small devices.


No it wasn't. That is something you invented yourself much later. "Small devices" isn't even defined anywhere, so there can't have been any such understanding.

The actual understanding was the opposite. Satoshi's words:

"At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware."

That is from 2008:
 
   http://satoshi.nakamotoinstitute.org/emails/cryptography/2/#selection-75.16-83.14

Then he went on to talk about Moore's law and streaming HD videos and the like. At no point did he ever talk about limiting the system for "small devices".

I have been both working on and using Bitcoin for longer than you have been around, Gregory. Please don't attempt to bullshit me about what the plan was. And stop obscuring what this is about. It's not some personality cult - the reason I keep beating you over the head with Satoshi's words is because it's that founding vision of the project that brought everyone together, and gave us all a shared goal.

If Satoshi had said from the start,

   "Bitcoin cannot ever scale. So I intend it to be heavily limited and used only by a handful of people for rare transactions. I picked 1mb as an arbitrary limit to ensure it never gets popular."

... then I'd have not bothered getting involved. I'd have said, huh, I don't really feel like putting effort into a system that is intended to NOT be popular. And so would many other people.


   >Don't think you can claim otherwise, because doing so is flat out wrong.


I just did claim otherwise and no, I am not wrong at all.

    >(Which, incidentially, is insanely toxic to any security argument for
    SPV; ---- and now we see the market failure that results from your and
    Gavin years long campaign to ignore problems in the mining ecosystem:


Since when have we "campaigned" to "ignore problems" in the mining ecosystem? What does that even mean? Was it not I who wrote this blog post?

    http://blog.bitcoinfoundation.org/mining-decentralisation-the-low-hanging-fruit/

Gregory, you are getting really crazy now. Stop it. The trend towards mining centralisation is not the fault of Gavin or myself, or anyone else. And SPV is exactly what was always intended to be used. It's not something I "fixated" on, it's right there in the white paper. Satoshi even encouraged me to keep working on bitcoinj before he left!


Look, it's clear you have decided that the way Bitcoin was meant to evolve isn't to your personal liking. That's fine. Go make an alt coin where your founding documents state that it's intended to always run on a 2015 Raspberry Pi, or whatever it is you mean by "small device". Remove SPV capability from the protocol so everyone has to fully validate. Make sure that's the understanding that everyone has from day one about what your alt coin is for. Then when someone says, gee, it'd be nice if we had some more capacity, you or someone else can go point at the announcement emails and say "no, GregCoin is meant to always be verifiable on small devices, that's our social contract and it's written into the consensus rules for that reason".

But your attempt to convert Bitcoin into that altcoin by exploiting a temporary hack is desperate, and deeply upsetting to many people. Not many quit their jobs and created companies to build products only for today's tiny user base.


My list of "things a full node is useful for" wasn't ordered by importance, by the way.


_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

#rekt

Most people do not understand the block size problem(s), and so discount the complexity. 

Fundamentally, the block chain presents a classic Garrett Hardin "tragedy of the commons" problem.  Each miner wins by getting their block accepted into the block chain, the bigger with more fees that can be accepted, the better.

Everyone else in "the commons" has costs commensurate with the block size except the winning miner.  Thus ultimately only miners are incentivised to maintain nodes and to do validation against the full chain.  This is all fine in the end game, where most are on board with Bitcoin.

We are no where near this today.  Those hoping we fail vastly outnumber those hoping we succeed, and have far greater resources.
So some carefulness is not wasted.  We will succeed simply by not failing.  The seeds of success are sown into the fabric of the Bitcoin code and architecture.

Oh not the sidechains debate again!

Yes all dev decisions are essentially centralized, including the decision to NOT do something.  Since that is trivially true, I am talking about the effect of the decision.  And in one case miners can optimize their profitability by choosing to include transactions while in another case they are artificially limited.

Brg444 asked if I was for completely lifting the limit.  I would be from a theoretical perspective but from practical engineering experience its makes sense to have what is called a "sanity check".  This is a limit that you expect to never be reached.  If it is, something is very wrong with the system.  Therefore if it was up to me, I would choose a bump to (say) 4 MB and then a periodic increase that mirrors txn adoption curves. 

If we were creating a more complex solution in a less constrained environment, I would let miners expand the block with high fee txns (which I described previously) and I would implement something that puts the limit at (say) 10x the average of last month's fee paying txns.  The problem with the latter though is that a miner could artificially expand the block size by including a bunch of fake txns is his own blocks.  This can be solved with a payout pool (half the txn value goes into the pool) rather than a direct payout.




By unique I was referring to people's inability to create new elements.  You can't just brew up gold 2.0 in the lab.  In that context silver is unique also.


Bitcoin and FinTech is invading the banker's space because of inefficiency.  Technology in all domains replaces low-tech solutions due to inefficiency.  Deliberately introducing inefficiency into the system (forcing a fee where one is not needed -- from the user's perspective efficiency is fee/amount transferred) is basically asking for new technology to replace bitcoin. 

The first apps to go will be colored coins (smart contracts) and immutable ledgers.  If these become useful, the money function of the chain that hosts them will have a much better operational efficiency (you don't have to move bitcoins into these coins, trade a stock, and then move them back).  If this coin/chain delivers similarly to Bitcoin on basic premises (scarce, decentralized, no premine etc) Bitcoin will be replaced.  In that case the BEST outcome for Bitcoin will be a gold analogy (store of value only).  However I have serious doubts about that because Bitcoin does not have gold's history, intrinsic value, etc.

Another outcome would be if a SC takes on the colored coins and immutable ledger function.  This would probably preserve Bitcoin's value since the SC is denominated in BTC.  Yet moving from SC to bitcoin chain is awkward so as Cypherdoc likes to argue all the coins might drain out of the bitcoin chain over to the SC.  I differ from him in my analysis because in this case at least BTC's value is preserved.  However, I find it hard to believe that a startup company would produce a SC with no advantage to themselves... they'll either produce a non-SC chain and out-mine other people in the early days or they'll be a per txn fee going to the startup.

Block (1) validation time as well as (2) propagation time are both issues for mining security and avoiding excessive forks/orphans which prolong effective confirmations.
They are separate issues however, and you can have either problem without the other in different blocks, or both together.

Both of these are exacerbated by block size.

As eager as I am for a block size increase for scalability, I'm not convinced that it is yet warranted given the risks...  The developers are aware of the issues.  They aren't goofing off.  It is just better to get it right than to get it done.

the exchanges is still going, if you have five mins just read it. Mike made a few others valid points imho in subsequent messages.
And those from  Thomas Zander deserve a quote.

Mike H just wrecked Eric on bitcoindev.

http://bitcoin-development.narkive.com/jsfcbpPz/why-satoshi-s-temporary-anti-spam-measure-isn-t-temporary#post10
Mike Hearn via bitcoin-dev 31 minutes ago

I do love history lessons from people who weren't actually there.

Let me correct your misconceptions.


Initially there was no block size limit - it was thought that the fee
Post by Eric Lombrozo via bitcoin-dev
market would naturally develop and would impose economic constraints on
growth.
The term "fee market" was never used back then, and Satoshi did not ever
postulate economic constraints on growth. Back then the talk was (quite
sensibly) how to grow faster, not how to slow things down!
Post by Eric Lombrozo via bitcoin-dev
But this hypothesis failed after a sudden influx of new uses. It was still
too easy to attack the network. This idea had to wait until the network was
more mature to handle things.
No such event happened, and the hypothesis of which you talk never existed.
Post by Eric Lombrozo via bitcoin-dev
Enter a “temporary� anti-spam measure - a one megabyte block size limit.
The one megabyte limit was nothing to do with anti spam. It was a quick
kludge to try and avoid the user experience degrading significantly in the
event of a "DoS block", back when everyone used Bitcoin-Qt. The fear was
that some malicious miner would generate massive blocks and make the wallet
too painful to use, before there were any alternatives.

The plan was to remove it once SPV wallets were widespread. But Satoshi
left before that happened.


Now on to your claims:

1) We never really got to test things out a fee market never really got
Post by Eric Lombrozo via bitcoin-dev
created, we never got to see how fees would really work in practice.
The limit had nothing to do with fees. Satoshi explicitly wanted free
transactions to last as long as possible.
Post by Eric Lombrozo via bitcoin-dev
2) Turns out the vast majority of validation nodes have little if anything
to do with mining - validators do not get compensated validation cost is
externalized to the entire network.
Satoshi explicitly envisioned a future where only miners ran nodes, so it
had nothing to do with this either.

Validators validate for themselves. Calculating a local UTXO set and then
not using it for anything doesn't help anyone. SPV wallets need filtering
and serving capability, but a computer can filter and serve the chain
without validating it.

The only purposes non-mining, non-rpc-serving, non-Qt-wallet-sustaining
full nodes are needed for with today's network are:

1. Filtering the chain for bandwidth constrained SPV wallets (nb: you
can run an SPV wallet that downloads all transactions if you want). But
this could be handled by specialised nodes, just like we always imagined in
future not every node will serve the entire chain but only special
"archival nodes"

2. Relaying validated transactions so SPV wallets can stick a thumb into
the wind and heuristically guess whether a transaction is valid or not.
This is useful for a better user interface.

3. Storing the mempool and filtering/serving it so SPV wallets can find
transactions that were broadcast before they started, but not yet included
in a block. This is useful for a better user interface.

Outside of serving lightweight P2P wallets there's no purpose in running a
P2P node if you aren't mining, or using it as a trusted node for your own
operations.

And if one day there aren't enough network nodes being run by volunteers to
service all the lightweight wallets, then we can easily create an incentive
scheme to fix that.


3) Miners don’t even properly validate blocks. And the bigger the blocks
Post by Eric Lombrozo via bitcoin-dev
get, the greater the propensity to skip this step. Oops!
Miners who don't validate have a habit of bleeding money: that's the
system working as designed.
Post by Eric Lombrozo via bitcoin-dev
4) A satisfactory mechanism for thin clients to be able to securely obtain
reasonably secure, short proofs for their transactions never materialized.
It did. I designed it. The proofs are short and "reasonably secure" in that
it would be a difficult and expensive attack to mount.

But as is so often the case with Bitcoin Core these days, someone who came
along much later has retroactively decided that the work done so far fails
to meet some arbitrary and undefined level of perfection. "Satisfactory"
and "reasonably secure" don't mean anything, especially not coming from
someone who hasn't done the work, so why should anyone care about that
opinion of yours?

Yes I see your point. As a solution to block size issue I think its fair to say its still complex.

That is not to say it shouldn't still be done - as you say it may be very useful for instant transactions. (I still think those can happen on chain though but time will tell)

Yes. Your situation re disk is different, and the pruning has known improvements to come.
Block relay optimization is more than "just" a factor of two gain, because unconfirmed tx are relatively uniform over a 10 minute window (so the network has an impressive capacity to handle these, as seen by how fast the mempool can grow), whereas blocks need to be sent at once, so ~600x data / second. Also, up-link is invariably slower than down-link which is a big concern for miners publishing blocks.

LN isn't really about fixing a perceived economic issue, it is about secure instant payments, something Bitcoin by itself can't do at all. The observation may be that if many routine/small transactions move to such a system, the need for such transactions on the main chain is reduced, but that is secondary. Even if the main chain had infinite capacity Lightning would still be extremely useful.

The introduction of sidechains, LN and whatever other solutions is a complicated solution. It's also a solution motivated by a desire to fix a perceived economic issue, rather than sticking to the very simple issue at hand. It is the very opposite of what you are claiming to be important, that software should be kept simple.

That is a contradiction.

The simple solution is to remove the artificial cap. A cap that was put in place to prevent DDOS.

Your reference of CVE-2013-2292 is just distraction. It is a separate issue, one that exists now and would continue to exists with a larger block size.

Great job on affirming your emotional attachment by posting inflammatory content, irrational argument and personal insults.

This may be true in general, but for the particular hosting company where I run my VPS, disk is the limiting factor in the decision when I have to upgrade to a more expensive plan.  With pruning, you can not fully support the network and you have to be careful with your wallet handling, as rescanning is not possible.  That's actually what I do on one of the VPS exactly because the blockchain is already too big for the plan I use there, but I would have preferred to run an unpruned full node if I could.  Increasing the block size makes this issue larger by orders of magnitude.

Furthermore, as stated above already, block relay optimisations also help only "little" with bandwidth.  (At best a factor of two in comparison to a much bigger increase in block size being discussed.)

Bandwidth is always a much bigger concern than blockchain usage on disk. TB disks are very cheap, v0.11 has pruning.

I'm not sure about that.  My opinion is that the biggest argument for retaining the cap (or, at least, not introducing a 20x plus exponential increase or something like that) is the burden on full nodes due to (cumulated) bandwidth, processing power and, last but not least, disk space required.  Of course, for miners the situation may be different - but from my own point of view (running multiple full nodes for various things but not mining) the block relay issue is not so important.  As gmaxwell pointed out, except for reducing latency when a block is found it does only "little" by, at best, halving the total bandwidth required.  Compare this to the proposed 20x or 8x increase in the block size.

I appreciate the further detail that you describe regarding the relay situation. So it seems that you are not optimistic that block propagation efficiency can have a major benefit for all full-nodes in the near future. Yet block propagation overhead is probably the single biggest argument for retaining the 1MB as long as possible. To cap volume growth to a certain extent.

I know that Lightning network and sidechains are orthogonal and not alternatives to relay improvements. However, I did not bring them up as a solution to dealing with the 1MB. Mentioning LN just now was prompted by Icebreaker's opinion that the prospect of LN is part of the reason why the 1MB should be left in place for some more years.
For the record. I like LN, I like its potential and I hope it succeeds.


BTW. Well done implementing BIP 66 the way you did.

Yes, all of Satoshi's posts about dotbit/Namecoin are 100% OFF-TOPIC and should be moderated.   

*makes justusranvier a copy of the Butthurt Report Form*