Gold collapsing. Bitcoin UP.

[cypherdoc]

i think the type of rogue block @humanitee is talking about, and that i worry about to a small degree, is the malicious miner, self constructed, multi input, non std, single tx mega block that chokes the network with the objective of destroying it. https://www.reddit.com/r/bitcoinxt/comments/3nclri/if_f2pool_can_construct_multi_dust_input_single/

i'm not worried about a Selfish Mining version of this as Gavin has said this would take at least 33% of the network hashing power and any honest pool that big won't want to destroy his own investment. thus, we are left with a malicious attacker like a bank or gvt who wants to disrupt Bitcoin as it's competitor. this still doesn't worry me that much b/c how big would they have to get to release a self mined (solo mined) malicious block like this? pretty big, i'd say, at least to do it with any frequency. and that would entail quite a hardware investment just to attack a network that could just as easily and perhaps unknowingly defeat this type of attack.

and then there's always the orphaning penalty for attempting to transmit a block too big.

i'm not worried at all about the tx paying spamming attacks in a no limit situation b/c at least the miners will be getting paid for them and full node validation doesn't go to waste. strengthening miner profits is the last thing an attacker would want to do.

*********************************************************************************************************

wow, this attack is a doozy. my nodes are still up but i think mine are overprovisioned comparatively. even so, i don't have *that* much swap left. i bet we see a few nodes get knocked off as a result of this:

 

[humanitee]

Exactly @cypherdoc

I worry about the unimagined shenanigans you can play by increasing the limit to infinity and letting the market decide. I love the way that sounds in theory, I just can't convince myself all attack vectors have been sorted out, and to be honest I can't fully imagine that level of market participation.

There is a natural downward pressure on infinity due to risk of orphaning, so that helps some.

What about UTXOs?

On a side note my mempool is 844.23652 MB. Wow. Gonna have to up the relayfee if it continues :[.

 

[Zangelbert Bingledack]

Market participation doesn't happen when the blocksize settings are centralized at Core HQ. If people had to choose their settings (well they wouldn't strictly have to, because there would be recommended settings and plenty of decentralized services helping out), they would actually consider the costs and benefits of various blocksize caps to their own personal use cases, creating a market result.

If you think that most nodes simply won't care enough to bother optimizing their settings, these aren't really the kinds of nodes that were helping decentralization anyway.

Whether it's attacks or edge case issues that are of concern, I see no case where individual nodes wouldn't be best equipped to make their own decisions given their own situations. Centralized blocksize controls seem little better than price controls. Take away price controls and people do figure out what to charge, because each person has their own profit and loss to estimate for their unique situation. The result is beautiful and resilient order, not chaos.

 

[humanitee]

So what about UTXOs? What happens if the market remains irrational longer than our memory can remain solvent?

Another question.
When we say "softcap" what are we really talking about? I can only softcap my limit, not yours. If you send me a block that's too big, then I must have a limit in there to recognize it's too big. If there isn't a limit, then there's no way for the network to actually limit the block size (what you are talking about). It's merely a risk of orphaning or being accepted. That means I can rapidly increase the block size and the UTXO size overnight if I have a well connected pool. We must remember that downstream bandwidth is typically an order of magnitude faster than upstream bandwidth. I could guise it as "good for the network" while filling UTXO and your hard drive.

 

[cypherdoc]

@humanitee

of course not everything can be known with certainty. but i certainly view UTXO set expansion as a much lower concern than absolute blocksize. if UTXO dust is owned by miners, then they can do consolidation tx's like f2pool did. if not, then just who would be willing to pay for each tx fee required to create a dust UTXO? esp if bigger blocks are leading to more tx's and higher prices? that could get very expensive to create.

when they say "softcap", what they mean is that miners should stick close together in terms of blocksize, inching forward towards larger and larger blocks so as not to suffer from orphaning from a single miner rushing too far ahead. remember that they should do this for quite a number of years still b/c, as that miner guy Marshall at Scaling said, "it's all about the reward".

then, if you say "rogue" miner like bank or gvt, you'll have to tell me exactly how they go about executing this attack.

 

[lunar]

I know lots of folk will disagree, but I really appreciate these stress tests. It gives everyone a glimpse into the future.

I feel like I'm in a brand new car on the Autobahn, stuck in first gear ... Come on, open it up, lets see what this baby can do.

Full nodes and Mempool storage settings will become a service industry in themselves. Companies will incentivise nodes to store their transactions and ensure they propagate efficiently

Balaji S. Srinivasan is already on this but others will follow
https://medium.com/@21dotco/the-21-full-nodes-index-f73a628b4762

 

[cypherdoc]

@lunarboy

"Companies will incentivise nodes to store their transactions and ensure they propagate efficiently"

no, companies will OWN their own nodes out of fiduciary duty thus vastly increasing their numbers.

 

[humanitee]

@humanitee

of course not everything can be known with certainty. but i certainly view UTXO set expansion as a much lower concern than absolute blocksize. if UTXO dust is owned by miners, then they can do consolidation tx's like f2pool did. if not, then just who would be willing to pay for each tx fee required to create a dust UTXO? esp if bigger blocks are leading to more tx's and higher prices? that could get very expensive to create.

when they say "softcap", what they mean is that miners should stick close together in terms of blocksize, inching forward towards larger and larger blocks so as not to suffer from orphaning from a single miner rushing too far ahead. remember that they should do this for quite a number of years still b/c, as that miner guy Marshall at Scaling said, "it's all about the reward".

then, if you say "rogue" miner like bank or gvt, you'll have to tell me exactly how they go about executing this attack.

Thank you for reply @cypherdoc.

The more I think through it, the more it seems possible.

 

[cypherdoc]

yes, yes, yes, mofo!:

 

[Peter R]

@Peter R - Yeah, I think that sounds right. And we'd be transparent with what size block we were "confident" in getting accepted.

FWIW, if we ever got to >30% hashpower, I'd suggest splitting the business into two completely separate entities with zero management/ownership overlap, but with the same stated business-model/charter. Thus, the fraction of the network that supports Bitcoin Unlimited could eventually exceed 50% without being a 51% threat.

I keep thinking about your idea. Perhaps the first step would be to create a ~2 page proposal that describes the project and its goals. We'd circulate it to select people and slowly add more names to the document as we found support. Based on the reception of the proposal, I think we'd find out pretty quickly if the idea had legs.

I guess we'd also need someone to fork Core to remove the limit. This is simple but it's probably important to have a real maintainer for the project. I don't think maintenance would be difficult: the maintainer just needs to merge all the best changes from Core / XT minus the block size hard limit code; he doesn't necessarily have to do any new development.

 

[cypherdoc]

fun stuff:

https://21.co/learn/introduction-to-bitcoin/#submit-bitcoin-tutorial-or-translation

 

[cypherdoc]

And so it begins:

http://www.zerohedge.com/news/2015-10-07/first-crack-deutsche-bank-preannounces-massive-loss-may-cut-dividend

 

[cypherdoc]

And another:

http://www.zerohedge.com/news/2015-10-08/day-after-deutsche-bank-admits-not-all-well-swiss-giant-credit-suisse-also-admits-it

 

[theZerg]

@humantiee change nodes to not relay very large blocks if they are near the end of the chain. If they are &gt N blocks deep then accept.

 

[cypherdoc]

off to a good start.

i actually fat fingered my entry pt yesterday @ 99.10 instead of 98.10. don't know how the hell i did that but i was rushing out the door to work when i set the trade. too bad, it did in fact get down to below 98 during the day and i just lost myself 1.1-1.2% pts right off the bat from carelessness:

 

[Bagatell]

I just started trading crosses and indirect pairs. There have been a few WTFs.

 

[cypherdoc]

setting new records everyday:

just wanna remind everyone just how tenuous the financial sector is. this is just JPM; they ALL look like this. w/o QE & bailouts, they'd be worthless:

 

[bitsko]

Hey cypherdoc. May I ask which software are you using to list your node statistics?

 

[Aquent]

LOL

Mike Hearn's posts are being deleted in r/bitcoin.

I don't get it. Why aren't miners mining XT? Knc said they will, antpool too, slush, 21inc can defo be persuaded as can bitfury. That's all we need. F2pool is the only one against but they showed their wisdom with implementing full rbf without having a clue about what they were doing and they are not needed anyway. So why aren't kncminers, antpool, slush, 21inc being lobbied to all start mining it at the same time together with bitfury and thus end this nonsensical debate?

 

[bitsko]

Aquent: I found this, related to talking to the miners...

"Can we please stop the "us versus them / winners and losers" rhetoric? Lets try to 'keep calm and bitcoin on.'

Here's what's going on with me:

I'm going to ignore the debate for a couple of weeks and write some code (pre-announcement of 'weak blocks' to optimize block propagation), mostly for my mental sanity, partly because showing insanely fast propagation of very large blocks eliminates the last technical objections.

Then I'm going to try to work with Greg/Pieter/Wlad/Jeff/peanut gallery to try to get a BIP based on resource usage that gets rough consensus. The BIP101 code includes resource usage constraint code that needs to get written into a BIP anyway.

If that succeeds, fantastic, we've got a path forward-- implement in XT, port to Core (and maybe backport six times for miners who insist on running old code), we all move forward.

If it is STILL impossible to get rough consensus, then another round of talking to exchanges and merchants and miners and either convincing them that BIP101 is the best choice or finding out what they want to do.

--
--
Gavin Andresen"

https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!topic/bitcoin-xt/SkNO-gnKiX0

Also, from further in the thread:

"Mike and I may disagree on this, but I have consistently said we have to have rough consensus with all the big exchanges and bitcoin-accepting businesses before asking miners to switch. So I haven't been asking miners to switch. I think it is sad to see miners "voting" for BIP100 in their coinbase transactions (for example) when there isn't even an implementation of BIP100 available yet."