Topic: Gold collapsing. Bitcoin UP. - page 142. (Read 2032266 times)

+1 for dry humor style points  


That was when I arrived in the thread.  

As long as he sticks to techno babble and steers clear of excessive ad hominem (against me for example that got his HF case revealed by vokain), then afaics he bolsters his case by remaining the owner of the most read thread on bitcointalk, i.e. in the bitcoin universe.

Note I am no longer fighting with him and I assume he has declared a truce with me also. Best for both of us. I have no skin in the HF debacle (although I feel for vokain et al, they need to learn and bounce back[1]). If he has cajones, Slypherdoc will invest some of his 3000 BTC in NewCoin and perhaps make off like a $billionaire bandit (untraceable). As for justice, don't people who fall for scams have some culpability too? The universe has a way of handing out justice. I lost my eye because of some decisions I had made. I had to own up to responsibility for it, i.e. involving the government in dispensing justice wasn't justified nor efficient. Life is too short.

[1] the day after the event on Dec. 1, 1999 that cost me blindness in my eye, I in my mind and heart forgave the guys who did it to me and decided to moveon. I don't have time for grudges. There is too much stuff I can still do. Until you render me incapable of doing anything, I will try my best to remain positive about life. I did however take up boxing as form of self-defense training and exercise since that event. And I continue to do sprinting training, because the smartest defense is often to run.

---

Perhaps all those who placed preorders with HF.

Actually you ask precisely the correct question, if you want to find the correct answer for decentralization. Hint, hint. But that answer is more clever and complex than I expect you to find.


You think that because you are blinded.

My well informed, prescient suggestion is wholeheartedly support the pegged side chain direction; otherwise prepare to exchange your BTC for another monetary unit or accept centralization.

Who decides what enough fees is?

I think this whole blocksize debate comes down to ideology.  It's not a technical decision. Some people think we need to keep 1 degree of freedom of control to shape Bitcoin "correctly," while others think we should let destiny take the wheel.

So you think that it would be best to simply put all that spam on the blockchain, and have everyone that ever wants to validate it go through that spam for eternity?  Wouldn't it be better to simply let the network and miners adjust their fee policies instead as they see fit and make sure that the spam is not even mined unless they pay "enough" fees?

Where can I find a specification for this extension blocks proposal, so I can determine how this proposal is differentiated from a pegged side chain?

Mike Hearn is so obviously for centralization it is a requirement to separate his objective points, and appears he may have a point about Lightning networks being not viable for much but very specialized interactions (which was also my upthread point about them).

I continue to think existing PoW designs are stuck between a rock and a hard place, thus I am very interested to read more detail about this proposal.

---

Edit: I found it, http://sourceforge.net/p/bitcoin/mailman/message/34157058/

The only way I see this is differentiated from pegged side chains, is it could be optionally a one-way transfer of BTC to the extension block chain, thus removes the need for the reliance on federated servers.

I understand that if address formats are differentiated between the two chains, then it is claimed one could pay from one chain to other but I can't see how that can work because the miners on the lower bandwidth chain would be SPV miners on the extension block chain. Thus all the dominos (due to orphaned chains) insecurity ramifications of pegged side chains which I argued upthread is untenable, unless you allow the BTC on each chain to have a different value. Afaics, the only reliable way to move pegged value back and forth between chains is as I wrote upthread with very long challenge periods on transferred funds and to use the Blockstream SPV proofs.

Thus one can view this proposal as a trojan horse to require Blockstream's pedded chains (and either the federated servers or the soft fork for the added OP code to eliminate the federated servers). Clever.

However, I still like the proposal for the same reasons I liked pegged side chains. But pleeeaaaase do it correctly. None of the mumbo jumbo about instant transfers between pegged chains. Sheesh.

And note this does nothing to solve the decentralization problem and rather just transfers the centralization to the extension block chain, because the 1MB chain can ultimately be 51% attacked because its relative block rewards will wither as debasement diminishes and transactions increase on the extension block chain (that is unless extension block transactions will have so extremely small fees and the 1MB chain sufficiently high enough fees which is very very unlikely because centralization by definition drives towards monopolistic pricing). Also because per math and economic reasoning above, solo mining is doomed any way.

looks like they may have turned off SPV mining.  that would be good.

but turning off minfee rules would only be used to include 0 fee tx's.

look at how much BTC value is included in that 37MB.

And you have the audacity to assert I am delusional for having faith in Armstrong's investment in his models and the performance I have observed thereof. At least I am not blind to the existence of my faith — as opposed to first hand knowledge of the open source, which you don't have either in the case of your Lord and I also doubt you've internalized all the source code that has been written by ongoing devs.

Haters gonna hate...

ftfy

Good point and more accurate is "we can only measure how we think it is". We don't even have absolute proof that someone isn't running a superior algorithm or hardware solution although we can often make very strong educated inductions.

Miners can't tell as soon as a block header is published, but they can tell once they get the block, according to Peters analysis bigger blocks take longer to propagate so SPV mining fills the gap until the block is known. So yes you're correct they can't know but not knowing isn't a good explanation as to why we see a higher percent of empty block after a big block.

I think you missed the economic reasoning, which is that pools have to compete at near 0 margins which means any losses due to overpaying some ephemeral miners during periods (e.g. any variant of pool hopping or just miners who come and go for any reason), is bankruptcy relative to those with larger hashrate share which don't incur that variance in profitability.

Variance such as in unit-of-exchange kills currency and it does the same concentrating effect on pools, as they are currently defined in the current network design for PoW coins (which btw I have a fix for[1]).

And that centralizing effect is exacerbated by the in-band (e.g. lower relative to hashrate latency and orphan rate) and out-of-band incentives (e.g. being paid to double-spend a 0-conf, etc) that may apply to any who may be running hidden monopolies via the Sybil attack, perhaps able to run at negative profit margins thus driving smaller pools extinct. Again I challenge any one to prove that pools are not Sybil attacked (meaning multiple pools being effectively owned by the same controlling entity). Since it can't be disproved, then Cypherdoc's assumption that miners are independent can not be proven to be true, yet it can be falsied by the math and economic reasoning I presented above (although some will refuse to admit the math because they can't falsify it with physical evidence).

All of this gets worse as bandwidth requirements are scaled up.

[1] my improvement over CN need not be anonymity (which could just be copied from CN), but rather network characteristics.

this is what they say on their website.  i should try to find out the exact #:

TradeBlock maintains an extensive bitcoin network data architecture with multiple nodes across geographies. With the ability to view and record every message broadcast to the network, including those that are not extensively relayed, unique insights regarding the network may be derived.

yeah, i had noticed that.  strange...

So one could assume those empty block would never be mined or would be orphaned should a competitor be SPV mining.

I'd also assume this phenomena is also only viable while the block subsidy is high enough that transaction fees are inconsequential. In the near future this strategy would most likely be optimized to including the minimum tx's that are low risk high reward to balanced against the risk of loss for the fiew seconds it would take to include in a block.

No clue, no node I have access to is seeing that much-- they may have turned off the minfee rules (not unreasonable for a metrics thing)...

Even given that, again, 37MB doesn't explain your swap.

Not yet, but I had the same idea!  Ugh…but right now I have to get back to non-bitcoin work...

i'm not really arguing about this with you.  you said UTXO is not in memory.  i'm saying it depends on how fast a node wants to verify tx's via the dynamic caching setting they choose which does get stored in memory.


Here I suspect you're suffering from an excess of empiracisism without adequately devling into the mechenism.   You can directly measure that time time from input to minable on an actual node under your control and will observe the time is hundreds of times faster than your estimate. Why?   Miners don't magically know when their pool has new work, they'll get work in the first milliseconds and then grind on it some time before submitting returning work.  Even if the pool long polls them, it takes time to replace work. So what I suspect you're actually measuring there is the latency of the mining process...  which is consistent with what we've expirenced with P2Pool (5-20 second latencies from ASIC miners are common).

I noted you posted a result of a classification, did you run the same data through a simple logistic regression with prior size as the treatment? The intercept in the model would be interesting.

But indeed, these conversations have been conflating several seperate issues (latency vs throughput, etc.). Tricky to avoid that since they're all relevant.

I have, they'd previously cranked it down, and were producing small blocks and were flamed in public.  They've since turned it back up.

As PeterR points out, they only need to wait for verification to actually verify (which they're not doing today), though they may have to wait longer to include transactions---- though I point out thats not fundimental e.g. no matter how big the backlog is you can produce a template sufficient to completely fill a block while doing no more work than handling a mempool of twice the maximum block size.  (by using a tiered mempool, though no one has bothered to implement this yet-- no one has even been complaining about how long createnewblock takes, due to the ability to produce empty blocks without skipping transactions).