Wondering out loud: Which should Chinese miners support - Core, Classic or another?

[BitUsher]

Excellent suggestion.

It fixes the glaring problems with the current reward structure, which is producing malallocation of resources (centralized ASIC farms sucking up all the block subsidies) and perverse incentives (externalized node costs, hacky SPV mining).

IIRC, this PoW is called Wild Keccak and has been used successfully by Boolberry for over a year.

Now who is going to code it up and get it into the BIP process/hard fork wishlist?

Seriously? I agree with the need to further develop an ASIC resistant PoW algo with Keccak , but anyone that is trying to promote MP's idea you cite really has no business in crypto.

This proposal is actually worth quoting in full before its get deleted or changed. If one takes the claim that this proposal was discussed at length in Mircea Popescu's group, then the conclusion is that his group doesn't have even a single student of cryptology, not to mention an amateur or professional cryptologist.

Salient Point. For those of intrest in why -

https://www.reddit.com/r/Bitcoin/comments/43qisj/paul_sztorc_on_twitter_it_seems_that_mircea/czka9we

So far, I've polled four Bitcoin Core engineers--I showed them the proposal and the median time until completely breaking the scheme is about 20 seconds. ... I'm not sure how much of that was just reading the page.

There are several different ways to achieve a total break of the scheme. One is that you simply fix your nonce to zero-- so you'll only hash the first byte (which also always happens to be a constant), and roll time and other fields instead.

Another is that you just soft-fork require (remember: we're constraining miners here) all blocks to be the same size... then you just pre-compute and incrementally update the million hashes. (This can also be combined with the one above, e.g. only scan nonces where nonce % 1e6 is less than 100 and compute 100 hashes). Even the full million midstates takes about 128 megabytes, more than a tad smaller than the whole blockchain.

The goal here isn't a new one, it often goes under the name of "Throughput proof of storage" or "storage throughput proof of work". You can see a far more reasonable version of it described on my alt ideas page from a few years ago, under "POW which involves queries against the UTXO set (set of spendable coins)".

Ignoring the cryptographic flaw in the approach; this requires the user have the whole historical blockchain to verify it. Eliminating the potential for pruning. There is no reason any Bitcoin node needs to be non-pruned except to help bootstrap new nodes onto the network. It also prevents any kind of lite node-- they can't verify this proof, so an attacker could mine without providing it enormously faster than an honest miner and deceive all the lite nodes. Talk about cutting off your nose to spite your face.

Amusingly, I suggested a much narrower idea in this space (not a throughput proof, but a knowledge proof) in early 2012, https://bitcointalk.org/index.php?topic=68396.0 to stop that year's version of verification-less mining... The author of this idea is the first response.

It would be interesting to find out how things would fare for a Bitcoin without the people who spot flaws in these cryptographic proposals in seconds flat. Interesting, but I suspect not so good for the market price for my Bitcoins.

That said, perhaps it is time to discuss some of the actually viable schemes which have been previously proposed for this. It's quiet easy to construct ones that aren't so obviously broken and which don't have terrible costs like breaking pruning, lite-nodes, etc..

[1715296663]

1715296663

[1715296663]

1715296663

[johnyj]

The July 04 fork IS a hard fork, a few nodes with majority of hash power mined the longest chain, and the consensus did not regard that longest chain to be valid.  The rule says that the longest chain should be the correct chain, but consensus says it is not. This is a perfect example that consensus decide what is bitcoin, not code.

The rule says the longest chain is only correct if it follows all the rules.  Simply being the longest is not enough.  The stupid miner announced support for BIP66 without actually supporting it.  He lost money, and was probably thought a lesson.  All nodes, both old and upgraded, were on the correct chain as soon as it overtook the malicious chain.

Obviously this is the designer being incompetent in analyzing all the possible scenario before they push out a change, because they don't fully understand the complexity caused by SPV mining. Miners just passively listen to designers, they don't have the ability to detect an error in a code that is not written by them

Gavin was blamed during 2013 fork, because an unexpected fork is always the fault of designer, because they pushed in a new change that caused that fork

But this time it is the other way around, when a fork happens, it is not designer's fault, it is miners instead! Ok, so devs are so smart and make miners lost money and blame it on them, do you think any sane person would still listen to those devs and lose money and get blamed again?

[iCEBREAKER]

Seriously? I agree with the need to further develop an ASIC resistant PoW algo with Keccak , but anyone that is trying to promote MP's idea you cite really has no business in crypto.

Well then, I guess Sztorc should leave crypto forever.  Nobody who has ever been wrong about something the past should be allowed in Bitcoin, so GMAX also has to go.

Oh wait, perhaps there is a difference between promoting consideration of an idea and being ready to die for it.

[BitUsher]

Seriously? I agree with the need to further develop an ASIC resistant PoW algo with Keccak , but anyone that is trying to promote MP's idea you cite really has no business in crypto.

Well then, I guess Sztorc should leave crypto forever.  Nobody who has ever been wrong about something the past should be allowed in Bitcoin, so GMAX also has to go.

Oh wait, perhaps there is a difference between promoting consideration of an idea and being ready to die for it.

The idea is fine in itself, as it was discussed years ago... but what MP has discovered in his "infinite wisdom" is a flawed concept of
storage throughput proof of work that has already been shown to be inadequate and flawed(Specific reasons cited).

Well then, I guess Sztorc should leave crypto forever.  

I am perfectly willing to accept that talented and capable people can make mistakes and occasionally agree with dumb ideas. In this case it may be due to a cult of personality blinding the judgment of fanboi's riding MP dick.... but who knows, perhaps you have a valid rebuttal to the concerns being addressed? Thus, perhaps they would be better off working with core devs instead of circle jerking on bitcoin-assets.

[iCEBREAKER]

Seriously? I agree with the need to further develop an ASIC resistant PoW algo with Keccak , but anyone that is trying to promote MP's idea you cite really has no business in crypto.

Well then, I guess Sztorc should leave crypto forever.  Nobody who has ever been wrong about something the past should be allowed in Bitcoin, so GMAX also has to go.

Oh wait, perhaps there is a difference between promoting consideration of an idea and being ready to die for it.

The idea is fine in itself, as it was discussed years ago... but what MP has discovered in his "infinite wisdom" is a flawed concept of
storage throughput proof of work that has already been shown to be inadequate and flawed(Specific reasons cited).

Well then, I guess Sztorc should leave crypto forever.  

I am perfectly willing to accept that talented and capable people can make mistakes and occasionally agree with dumb ideas. In this case it may be due to a cult of personality blinding the judgment of fanboi's riding MP dick.... but who knows, perhaps you have a valid rebuttal to the concerns being addressed? Thus, perhaps they would be better off working with core devs instead of circle jerking on bitcoin-assets.

Let's not lose sight of the salient point: MP is now willing to eventually support a hard fork raising the blocksize, provided an improved PoW is part of the deal.

The big news here isn't the exact proposal under consideration, but rather the type and character of a proposal now endorsed by a guy who represents a segment of the socioeconomic majority with veto power over other, competing hard forks.

You seem to greatly resent bitcoin-assets holding such veto power, hence your homophobic ranting about "riding MP dick" and "circle jerking."

But rather than petulantly attacking the source of the proposal, why not focus on improving its deficiencies?

You could contribute positively to the discussion by explaining why the 20-second hacks (set nonce to zero; soft fork to uniform blocks) haven't broken Boolberry's similar Wild Keccak PoW.

Is it because there are no entrenched ASICs in the BBR space, or because the market cap is too tiny to bother, or some technical difference?

[hdbuck]

MP is just messing with you, he is just ensuring there is just no way 2MB fork happens. ever.

[johnyj]

Huh?  The bitcoin blocks are still valid bitcoin blocks when segwit is deployed.  Transactions with a segregated witness will have the signature in a separate chain, but this does not change the validity of the block.  The blocks and the transactions in the blocks are perfectly valid to all nodes.

Only upgraded nodes will know how to check the validity of transactions where the spent txout is from a transaction with segregated witness, but this won't be a problem.  It won't activate until at least 95% of the hashrate support it.  Any chainforks will therefore be short, and can not be hard.

It is so easy to understand: Suppose that 5% of old nodes don't understand how to verify segwit blocks, so they accept segwit blocks regardless if they are valid

Now some segwit miner mined a segwit block with invalid signature data, that block will be rejected by the Segwit nodes, but accepted by old nodes since they can not verify the signature part, so the old nodes start to build new blocks upon that block, and if they add one block upon that invalid block, you have a hard fork, now two chains have different history thus will never merge

[iCEBREAKER]

MP is just messing with you, he is just ensuring there is just no way 2MB fork happens. ever.

Ah yes the old poison pill, like my BIP1337 idea (IF max_size = 2MB, THEN target_time = 20 minutes).   

[BitUsher]

You seem to greatly resent bitcoin-assets holding such veto power, hence your homophobic ranting about "riding MP dick" and "circle jerking."

There was absolutely nothing homophobic about my statements as I have heard that behavior isn't gay in the slightest if you avoid eye contact and say "no-homo" afterwords.

Let's not lose sight of the salient point: MP is now willing to eventually support a hard fork raising the blocksize, provided an improved PoW is part of the deal.

The big news here isn't the exact proposal under consideration, but rather the type and character of a proposal now endorsed by a guy who represents a segment of the socioeconomic majority with veto power over other, competing hard forks.

MP would do the community a large favor by pulling a Hearn-like ragequit and leaving our ecosystem. His ego is much greater than his ability, which in itself isn't that bad , but we shouldn't tolerate people advocating the solicitation for murdering people for thought crime. Whether he is trolling or not , doesn't matter, as he has developed a dangerous cult of personality where some of his readers may follow his advice.

But rather than petulantly attacking the source of the proposal, why not focus on improving its deficiencies?

You could contribute positively to the discussion by explaining why the 20-second hacks (set nonce to zero; soft fork to uniform blocks) haven't broken Boolberry's similar Wild Keccak PoW.

Is it because there are no entrenched ASICs in the BBR space, or because the market cap is too tiny to bother, or some technical difference?

I agree with this sentiment. Yes, you answered your own question, but I don't see much use in wasting too much time proving it because, while I do appreciate the naive attempt MP was making in proposing a valid solution to a flaw in Bitcoins architecture, it wasn't enough. A better solution would be in developing an ASIC Proof Keccak PoW to address the larger problem of mining centralization in addition to node count dropping off.

More details expressed here-
https://medium.com/@vcorem/lesson-learned-from-the-classic-coup-attempt-or-why-core-needs-to-prepare-a-gpu-only-pow-6a9afe18e4b0#.eg909s983
https://bitcointalk.org/index.php?topic=359323.0

MP is just messing with you, he is just ensuring there is just no way 2MB fork happens. ever.

It doesn't matter if he is trolling , because a) His troll attempt was flawed and in a few moments many could see he had no idea what he was talking about. b) Anyone who advocates for 1MB forever is dangerous and not placing important principles ahead of some arbitrary number.  

[sturle]

WTF?  But why?  Finally there is RBF and all the other improvements in 0.12, which are important to users, merchants and exchanges, and Oliver Janssen decides to not support it? Again: WTF is Classic about?  I thought is was a fork to 2 MB block size, not a retardation.

They are clearly just spooking.  Noone in their right mind will run it.  When 90% of nodes use RBF, and 0.12 doesn't even inform about RBF transactions, it would be outright dangerous to use.  I can send a 0-fee transaction to a "Classic" user, insist on getting my money now, and then RBF it.  Even easier than it is now.  With RBF support, I can instead ask the sender to replace it by a non-RBF transaction paying a fee.

I intend to use RBF a lot myself.  I exchange bitcoins all the time, and as long as I have an unconfirmed transaction in the queue, I can just replace it and add outputs as I sell more.  Saving transactions on the blockchain, ensuring faster confirmations for my customers, and not having to use unconfirmed inputs.

And the speed improvements important for IBD?  Why don't they want them?  Or the data limits, etc?  All of those must be essential for a large block fork.

Because Core hasn't paid enough attention to solving the block size problem. We shouldn't be where we are now.

Or because it's all a big evil conspiracy. Take your pick.

Blaming Core doesn't make sense.  They already implemented those features in 0.12!  I personally think the problem is incompetence.  The forks lack competent programmers, and don't know how to merge the fork they made with current Bitcoin.  They made something they think may work on top of some old version, and don't dare to touch it.

The block size is currently not a problem, and won't be for a while yet.  Hard forks will be, especially if the forks keep pretending to be Bitcoin.

Aqually it should be doable by a lot less than 25%, since you can generate every block a 10 minute to validate block, and it will be very hard for the rest to catch up.  If the fork happens, Bitcoin will already be destroyed, so the investment is already lost.  The only cost is power.

So if Bitcoin is already destroyed someone will stay behind to savage the corpse? I am speechless...

Of course.  Can you think of a better use for the equipment?

Of course it does. I agree that there needs to be more focus on efficiency, but my view (and that of quite a few others as well) is that we can't let the cow starve while the grass is growing. And this seems to be the main point of contention.

Letting the cow die in a civil war isn't much better.

... the civil war which was started in order to save the cow from starving?

The cow isn't starving.  The blocks aren't full, except during spam attacks which would have filled blocks of any size.  Not even then, since most miners don't produce full blocks under any circumstance.  Normally, e.g. now, it is far between full blocks.  Some miners are quite good at filtering the spam, and confirm even 0-fee transactions in the first block they make even during the worst spam storms.  Doubling the size of the what field won't help a bit, when you don't do sh*t about the real problem.  Swarm of grasshoppers and birds eating everyting they get.

Are we going to have an equally fruitful debate about the word "full" as we had about "released"?

Scroll around and look at the recent blocks:

https://tradeblock.com/bitcoin/

https://blockchain.info/

There's not a lot of room for growth.

By the way, nice metaphor for adoption: "Swarm of grasshoppers and birds eating everyting they get."

Adoption?  It that what you call transaction spam?  Do you think 2 MB blocks will reduce the spam in any way?  The blocks will be just as full.

I just had a look.  Of the last 8 blocks, only one is close to full.  1.8 kB left in that one, which should allow for about 9 more non-segwit transactions.  The rest have plenty room.  The blocks which are completely full usually contain a lot of dust transactions, i.e. outputs which cost more in fees tp spend than the value of the output, which won't get mined using a default configurations.  Some miners happily prefer those transactions as long as they pay more in fees.  This is abuse, imho.

Here is a nice infographic which explains why segwit is a much better idea than some panic fork blocksize war.

[tomothy]

"Adoption?  It that what you call transaction spam?  Do you think 2 MB blocks will reduce the spam in any way?  The blocks will be just as full.

I just had a look.  Of the last 8 blocks, only one is close to full.  1.8 kB left in that one, which should allow for about 9 more non-segwit transactions.  The rest have plenty room.  The blocks which are completely full usually contain a lot of dust transactions, i.e. outputs which cost more in fees tp spend than the value of the output, which won't get mined using a default configurations.  Some miners happily prefer those transactions as long as they pay more in fees.  This is abuse, imho.

Here is a nice infographic which explains why segwit is a much better idea than some panic fork blocksize war."


1) You mention of the last 8 blocks, one is near full with 1.8 kb left. You suggest this could allow 9 more transactions? So theoretically, you are saying, if the usage of bitcoin had increased, and 10 more people, tried to send a transaction during this time period, the block would have been full and those transactions would not have been included? Is this accurate? Since very few people use bitcoin, it seems self-evident, that if adoption increases, the likelihood of full blocks increase. Is this correct?

2) You then mention there are dust transactions, outputs which cost more in fees to spend, than the value of the output. If I'm sending a bitcoin from A to B, would this be considered a dust transaction? There isn't much included, correct? Assuming this is the case, since I'm moving a fair amount of money, wouldn't it be safe to say that I would want to ensure that this transaction takes places and increase the fee? Forgive my ignorance with this regard. Or would it only be spam if I was for example sending .00099 btc and I had a fee of .001 btc to ensure that the transaction was hopefully included in a recent block? Perhaps a better exampled would be, me needing to send btc to my brother in Germany. I want to make sure he gets it, that the transaction is included, so say I send .05 with a fee of .05 or a permutation of that with .049 and .05 or .05 and .049.

3) How would this(the above mentioned) be considered abuse? In either of the above mentioned transactions I need to get him ~$20USD for whatever reason I have. This seems like legitimate usage, no? How is the determination made whether usage is an abuse or not?                     

Thanks.

[iCEBREAKER]

Interesting perspective from our brothers in the east.

Miners aren't that critical

https://bitcoinzh.com/miners-are-not-that-critical

Miners aren't that critical, original Chinese text from Bikeji.com

Are we sure we want to increase to 2MB right now?

I remember when XT was being pushed out, Gavin was saying if we don’t expand block sizes there’ll be all kinds problems. We haven’t expanded, have any problems appeared after all? It reminds me of an expression, I forget who said it, but most of the things you worry about just won’t happen. So even if we don’t increase, I don’t think anything major will happen to Bitcoin. At worst maybe the price won’t go up as you’d like, but that’s nothing really. We’re all 10-year, loyal holders.

Actually, the reason I suggest not increasing to 2MB now is, I want to see just what is caused by blocks being full. This hasn’t happened before, so it’s a chance for us to experience whether or not it’s as critical as Gavin says. I don’t think it will be. Last time, to win support for XT, Gavin was sensationalizing and nothing more. If Bitcoin could die just like that, well then it wouldn’t be much loss.

Rights & responsibilities

The most frequent refrain in the block size debate has been centralization of the Bitcoin code. In fact, whatever the issue, rights and responsibilities are intrinsically linked. It’s just like with mining, CPU gives you rights, but it also gives you responsibility - to protect the network. In the same way, protecting Bitcoin’s code may appear as power, but it’s actually a responsibility.

Even if the code were being centralized, this would be a result of people’s inactions at normal times. We don’t usually assume any greater responsibility, so at these critical junctures, we don’t have greater rights to a voice. This would apply in any domain. So if anyone has something to say, any suggestions, you can closely follow how the code is looked after and make contributions to the Core developers. If everyone just acts in their corporate interests, then we won’t have anything worth saying and I for one won’t be complaining.

Of course, I still have my vote and can leave at any time. Although I don’t currently think there’s any problem with Core. As far as I can see, their’s is a long-sighted proposal.

Who are our allies?

Who are our allies in this affair? It’s often hard to tell. Like Mike releasing XT then making a run for it. I still don’t get why someone who’d sold all their coins would care so much about making a hard fork.

As a bitcoin holder, I can only confirm that miners are our allies. They’ve invested real dollars. We’ve all witnessed their hashing power, there’s no faking that. But what about developers? We don’t really know whether they hold any coins or not. I couldn’t trust anyone who could support a fork at 75% consensus without regard for the miners’ interests. For the very simple reason that I don’t know whether you have skin in the game whereas with miners it’s out in the open. So if someone isn’t looking out for the interests of miners, then they aren’t an ally. That’s why Gavin fell sharply in my estimation when he released XT.

Who’s the weak one?

Actually Bitcoin does have a way of controlling the situation when blocks are full. If a serious bug appears, achieving consensus and implementing a hard fork is simple because everyone has an economic interest. Why is it that we’ve been arguing about block size expansion for so long but haven’t reached consensus? Because there’s no rush!

If the consequence of having blocks at capacity were network paralysis, I’m sure within 24 hours the hard fork would be implemented and successfully so. But clearly, if blocks are full then blocks are just full and it’s not the end of the world. During the spam attack stress-test and over the few days when there are price bubbles, blocks are basically at capacity.

What’s that you say? The user experience is terrible? New users can’t join the network? The price is depressed? Lol, don’t you want the cheap coins? Whatever way you look at this, the weak point isn’t Bitcoin, it’s us. Maybe the price will rise too slowly, if so we’ll speed up. Maybe some people are plotting to profit from the price fall, deliberately creating panic.

Whatever you do or don’t do then, don’t stop hodling!

Thank you for posting that!  I especially like the fresh (original?) "Rights & responsibilities" analysis, as well as the point that Classic's 75% attack throws miners under the bus.

This guy really gets it; it's a pleasure to observe him grokking the ethos.

So much for the OP's impression that all Bitcoiners in China demand 2MB right fucking now, Because Respect.  That narrative just exploded, right in Gavin's face.   

[sAt0sHiFanClub]

"Adoption?  It that what you call transaction spam?  Do you think 2 MB blocks will reduce the spam in any way?  The blocks will be just as full.

I just had a look.  Of the last 8 blocks, only one is close to full.  1.8 kB left in that one, which should allow for about 9 more non-segwit transactions.  The rest have plenty room.  The blocks which are completely full usually contain a lot of dust transactions, i.e. outputs which cost more in fees tp spend than the value of the output, which won't get mined using a default configurations.  Some miners happily prefer those transactions as long as they pay more in fees.  This is abuse, imho.

Here is a nice infographic which explains why segwit is a much better idea than some panic fork blocksize war."


1) You mention of the last 8 blocks, one is near full with 1.8 kb left. You suggest this could allow 9 more transactions? So theoretically, you are saying, if the usage of bitcoin had increased, and 10 more people, tried to send a transaction during this time period, the block would have been full and those transactions would not have been included? Is this accurate? Since very few people use bitcoin, it seems self-evident, that if adoption increases, the likelihood of full blocks increase. Is this correct?

2) You then mention there are dust transactions, outputs which cost more in fees to spend, than the value of the output. If I'm sending a bitcoin from A to B, would this be considered a dust transaction? There isn't much included, correct? Assuming this is the case, since I'm moving a fair amount of money, wouldn't it be safe to say that I would want to ensure that this transaction takes places and increase the fee? Forgive my ignorance with this regard. Or would it only be spam if I was for example sending .00099 btc and I had a fee of .001 btc to ensure that the transaction was hopefully included in a recent block? Perhaps a better exampled would be, me needing to send btc to my brother in Germany. I want to make sure he gets it, that the transaction is included, so say I send .05 with a fee of .05 or a permutation of that with .049 and .05 or .05 and .049.

3) How would this(the above mentioned) be considered abuse? In either of the above mentioned transactions I need to get him ~$20USD for whatever reason I have. This seems like legitimate usage, no? How is the determination made whether usage is an abuse or not?                     

Thanks.

He is talking rubbish, like he has for the last few posts. He fancies himself as the "arbiter of bitcoin - its only a transaction if I say so...."  

So much for the "censorship resistant" nature of bitcoin. Why would anyone use bitcoin over paypal if you had to send an email to this guy in advance to see if the transaction was acceptable to him or not. Jesus wept.  And he has the temerity to call other people Dictators? Ha.

Thankfully, bitcoin was designed so that pragmatic miners are rewarded for processing tx's irrespective of their size, as long as they pay an appropriate fee.

[sturle]

1) You mention of the last 8 blocks, one is near full with 1.8 kb left. You suggest this could allow 9 more transactions? So theoretically, you are saying, if the usage of bitcoin had increased, and 10 more people, tried to send a transaction during this time period, the block would have been full and those transactions would not have been included? Is this accurate? Since very few people use bitcoin, it seems self-evident, that if adoption increases, the likelihood of full blocks increase. Is this correct?

No, not even close.   If you have been using bitcoin for more than a day, you should know there are two concepts called "fee" and "priority".  If ten more people had sent transactions at the same time, and they included a fee at all, or the input utxos had any confirmations at all, the transactions would be included.  I send many of my transactions with a very low or zero fee to mark them as low priority, can wait if the block is full.  They almost never have to wait.

2) You then mention there are dust transactions, outputs which cost more in fees to spend, than the value of the output. If I'm sending a bitcoin from A to B, would this be considered a dust transaction?

You obviously don't know what dust is, and I doubt you know how transactions are constructed.

A transaction has inputs and outputs.  Each input is a reference to an earlier transaction output by txid and number of an outoput in the given txid.  When an input is spent, the entire input is spent.  When all outputs from a txid have been spent, the txid can be pruned from the utxo set (which is good).

A dust output is an output of just a few satoshis.  So small that including it in a transaction would increase the necessary fee for the transaction more than the value of the input.  I.e. it will never be possible to spend economically, and litter the utxo space forever.  No matter how many such inputs you have, the combined value of them is negative.  Those utxos are called dust.  We don't want transactions containing dust outputs, because those will litter the utxo set, which is kept in memory on all nodes, forever.  

Was that clear?  Faster increasing UTXO set is Gavin's main argument against a block size increase, btw.  Dust is the worst, since it is economically unspendable, and will stay there forever.

There isn't much included, correct? Assuming this is the case, since I'm moving a fair amount of money, wouldn't it be safe to say that I would want to ensure that this transaction takes places and increase the fee? Forgive my ignorance with this regard. Or would it only be spam if I was for example sending .00099 btc and I had a fee of .001 btc to ensure that the transaction was hopefully included in a recent block? Perhaps a better exampled would be, me needing to send btc to my brother in Germany. I want to make sure he gets it, that the transaction is included, so say I send .05 with a fee of .05 or a permutation of that with .049 and .05 or .05 and .049.

0.00099 is far above the dust threshold.  It is 513 satoshis or thereabouts.  The monetary value, even assuming 0 txfee, is much less than one cent.

3) How would this(the above mentioned) be considered abuse? In either of the above mentioned transactions I need to get him ~$20USD for whatever reason I have. This seems like legitimate usage, no? How is the determination made whether usage is an abuse or not?                    

I have no idea why anyone would consider what you explain there abuse.

[sAt0sHiFanClub]

Bitcoin has been designed to work fine without incoming connections.  A non-upgraded node can make outgoing connections to anyone.  All nodes.  Upgraded or not.  Upgraded nodes will accept incoming connections from anyone.  Upgraded or not.  The only change he is suggesting, is to make sure upgraded nodes only make outgoing connections to other upgrading nodes.  My own node currently has 8 outgoing and 104 incoming connections.  Even if my node is upgraded, and all my outgoing connections are to segwit nodes, there is nothing whatsoever stopping non-upgraded nodes to connect to my node, and nothing is splitting the network in any way imaginable.

How does a peer to peer network work if all nodes only make outgoing connections? How does that work exactly?

[Fatman3001]

WTF?  But why?  Finally there is RBF and all the other improvements in 0.12, which are important to users, merchants and exchanges, and Oliver Janssen decides to not support it? Again: WTF is Classic about?  I thought is was a fork to 2 MB block size, not a retardation.

They are clearly just spooking.  Noone in their right mind will run it.  When 90% of nodes use RBF, and 0.12 doesn't even inform about RBF transactions, it would be outright dangerous to use.  I can send a 0-fee transaction to a "Classic" user, insist on getting my money now, and then RBF it.  Even easier than it is now.  With RBF support, I can instead ask the sender to replace it by a non-RBF transaction paying a fee.

I intend to use RBF a lot myself.  I exchange bitcoins all the time, and as long as I have an unconfirmed transaction in the queue, I can just replace it and add outputs as I sell more.  Saving transactions on the blockchain, ensuring faster confirmations for my customers, and not having to use unconfirmed inputs.

And the speed improvements important for IBD?  Why don't they want them?  Or the data limits, etc?  All of those must be essential for a large block fork.

Because Core hasn't paid enough attention to solving the block size problem. We shouldn't be where we are now.

Or because it's all a big evil conspiracy. Take your pick.

Blaming Core doesn't make sense.  They already implemented those features in 0.12!  I personally think the problem is incompetence.  The forks lack competent programmers, and don't know how to merge the fork they made with current Bitcoin.  They made something they think may work on top of some old version, and don't dare to touch it.

The block size is currently not a problem, and won't be for a while yet.  Hard forks will be, especially if the forks keep pretending to be Bitcoin.

I'd advice you to stop deleting parts of the conversation if you can't remember what I wrote.

I hope they are going to upgrade to 0.12 before they release.  0.12 has lots of improvements, e.g. much faster IBD, data usage limiting, the long awaited RBF feature, etc.  It will be hard to convince people to downgrade.

The first version will be 0.11.2 with a 2MB block size. It may very well be the final version if Core decides to wise up.

Doesn't seem to be a serious attempt then.  Are the Toomins too incompetent to merge the improvements from 0.12?

The choice of 0.11.2 was a conscious decision in order to make it perfectly clear what this release of Classic is about.

They wanted everything else than the 2MB block size limit increase to be uncontroversial. This is best achieved with 0.11.2. Not everyone are as enthusiastic about RBF as you are.

Aqually it should be doable by a lot less than 25%, since you can generate every block a 10 minute to validate block, and it will be very hard for the rest to catch up.  If the fork happens, Bitcoin will already be destroyed, so the investment is already lost.  The only cost is power.

So if Bitcoin is already destroyed someone will stay behind to savage the corpse? I am speechless...

Of course.  Can you think of a better use for the equipment?

Door stops. Buttplugs. Who gives a hoo-haa at that point?

Of course it does. I agree that there needs to be more focus on efficiency, but my view (and that of quite a few others as well) is that we can't let the cow starve while the grass is growing. And this seems to be the main point of contention.

Letting the cow die in a civil war isn't much better.

... the civil war which was started in order to save the cow from starving?

The cow isn't starving.  The blocks aren't full, except during spam attacks which would have filled blocks of any size.  Not even then, since most miners don't produce full blocks under any circumstance.  Normally, e.g. now, it is far between full blocks.  Some miners are quite good at filtering the spam, and confirm even 0-fee transactions in the first block they make even during the worst spam storms.  Doubling the size of the what field won't help a bit, when you don't do sh*t about the real problem.  Swarm of grasshoppers and birds eating everyting they get.

Are we going to have an equally fruitful debate about the word "full" as we had about "released"?

Scroll around and look at the recent blocks:

https://tradeblock.com/bitcoin/

https://blockchain.info/

There's not a lot of room for growth.

By the way, nice metaphor for adoption: "Swarm of grasshoppers and birds eating everyting they get."

Adoption?  It that what you call transaction spam?  Do you think 2 MB blocks will reduce the spam in any way?  The blocks will be just as full.

I just had a look.  Of the last 8 blocks, only one is close to full.  1.8 kB left in that one, which should allow for about 9 more non-segwit transactions.  The rest have plenty room.

That is just silly-talk. Last I checked all the blocks were 900kB+. Ideally it should be no more than 10-20% full in order for the network to be ready to absorb more users.

The blocks which are completely full usually contain a lot of dust transactions, i.e. outputs which cost more in fees tp spend than the value of the output, which won't get mined using a default configurations.  Some miners happily prefer those transactions as long as they pay more in fees.  This is abuse, imho.

Do you have any data to back up your claim of the prevalence of dust spam in blocks now?

Here is a nice infographic which explains why segwit is a much better idea than some panic fork blocksize war.

In case you don't remember:

I hope Core replies with a 2MB/Segwit hard fork. It seems like a clever piece of technology. But I wasn't talking about Segwit. Segwit will only get us so far.

[BlindMayorBitcorn]

Ideally it should be no more than 10-20% full in order for the network to be ready to absorb more users.

How come Fatty?

[Fatman3001]

Ideally it should be no more than 10-20% full in order for the network to be ready to absorb more users.

How come Fatty?

To handle spikes in trade when they appear.

To handle a grass root adoption wave, or to show any industry interested that Bitcoin can and will meet their needs, it should probably be more.

I guess you could claim that it would be enough to know that 20x tx/s or similar is theoretically possible to satisfy this last bit, but it turns out that getting people to implement the necessary capacity increases is not as straight forward as it should be.

[BlindMayorBitcorn]

Ideally it should be no more than 10-20% full in order for the network to be ready to absorb more users.

How come Fatty?

To handle spikes in trade when they appear.

To handle a grass root adoption wave, or to show any industry interested that Bitcoin can and will meet their needs, it should probably be more.

I guess you could claim that it would be enough to know that 20x tx/s or similar is theoretically possible to satisfy this last bit, but it turns out that getting people to implement the necessary capacity increases is not as straight forward as it should be.

Non-political money is more political than one would imagine.

[sturle]

Bitcoin has been designed to work fine without incoming connections.  A non-upgraded node can make outgoing connections to anyone.  All nodes.  Upgraded or not.  Upgraded nodes will accept incoming connections from anyone.  Upgraded or not.  The only change he is suggesting, is to make sure upgraded nodes only make outgoing connections to other upgrading nodes.  My own node currently has 8 outgoing and 104 incoming connections.  Even if my node is upgraded, and all my outgoing connections are to segwit nodes, there is nothing whatsoever stopping non-upgraded nodes to connect to my node, and nothing is splitting the network in any way imaginable.

How does a peer to peer network work if all nodes only make outgoing connections? How does that work exactly?

That wouldn't work, of course.  Another reason not to worry.  Unfortunately many nodes are behind NAT and/or restrictive firewalls, and cannot accept incoming connections.  Nodes which are on a public IP, and accept incoming connections, often have a hundred or more.