Gold collapsing. Bitcoin UP.

[AdrianX]

The mods are pathetic.

I just re-submitted my animated pie-chart that visualized the deprecation of Bitcoin Core (this was the submission that was previously censored for "vote brigading"). It made it half way up the front page and then it was censored. I wrote the moderators to ask which rule I broke and frankenmint responded that he removed it because it had been removed in the past. I explained that it was apparently removed in the past for "vote brigading" and not because the content was banned. We'll see how he replies...

https://www.reddit.com/r/Bitcoin/comments/3osfb8/deprecating_bitcoin_core_visualizing_the/

EDIT: he says that upon reflecting, the pie chart promotes consensus-breaking client software and is not allowed.

LOL, bitcoins is broken didn't you know, they are fixing it for you ;-)

its frustrating to see such ignorance being so confident. sure is sad.

 

[cypherdoc]

 

[AdrianX]

I'll reiterate my suggestion to read the Pieter Hintjens book I linked earlier today.

Building a community that will resist fracturing attempts like what have been successfully employed against Bitcoin requires particular precautions to be taken, which he outlines in the book.

@Justus Ranvier do you recommend any particular chapter.

 

[Justus Ranvier]

Just one chapter? Doesn't everybody have time to just sit down and read a 300 page book cover to cover on a whim?

I guess chapter 6, specifically the "The Project Group" section.

 

[cypherdoc]

back over the 200. hang on:

[doublepost=1444877989,1444877344][/doublepost]

another good inside on LN from Paul Sztorc:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011525.html

here's the problem with Sztorc and his claims:

On 10/14/2015 6:37 PM, s7r wrote:
> On 10/14/2015 6:19 PM, Paul Sztorc wrote:
>> LN transactions are a substitute good for on-chain transactions.
>
>> Therefore, demand for on-chain transactions will decrease as a
>> result of LN, meaning that fees will be lower than they would
>> otherwise be.
>
>> However, the two are also perfect compliments, as LN transactions
>> cannot take place at all without periodic on-chain transactions.
>
>> The demand for *all* Bitcoin transactions (LN and otherwise) is
>> itself a function of innumerable factors, one of which is the
>> question "Which form of money [Bitcoin or not-Bitcoin] do I think
>> my trading partners will be using?". By supporting a higher rate of
>> (higher-quality) Bitcoin transactions, the net result is highly
>> uncertain, but will probably be that LN actually increases trading
>> fees.
>
> Probably yes. But probably no. Having less hashing power is not good,
> and it's unrelated to scalability and decentralization, it's related
> to security. Of course we could argue that the hashing power is not
> super decentralized at this moment but it's unrelated to the topic.
Who are you talking to? Who said anything about any of this? If you are
talking to me, please don't imply that I don't already know these things.

>
> I'd rather have less decentralized big amount of hashing power as
> opposite to less hashing power.
>
> One theory, very close to yours, is that if Bitcoin transactions
> demand grows so high that we need the lightning network, there should
> be plenty of on chain transactions for miners to collect fees from.
For a given fee amount, LN transactions are worse than on-chain
transactions. So people would only use LN if they preferred cheaper txns.
>
> I haven't yet seen the incentives of everyone involved in lightning
> network (payment channel end points, hub operators, miners, etc.) but
> would it make sense to enforce a % of the fees collected by on payment
> hubs to be spent as miner fees, regardless if the transactions from
> that hub go on the main chain or not?
If you want fees to go up, either decrease supply (lower the blocksize
limit) or increase demand (a popular Bitcoin). There's no need to do
anything roundabout.

Regards,
Paul


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

NO ONE knows what the right blocksize is and what the resulting fee pressures will be. to suggest one knows is to not understand the economics of the situation.

the only way to know is to lift the block size entirely, setup LN, and then let the free mkt figure it out.
[doublepost=1444878516][/doublepost]*****************************************************
********************************************************

great article and heads up:

https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/
[doublepost=1444878977][/doublepost]
*********************************************************
********************************************************
up, up, & away!
[doublepost=1444879152][/doublepost]
***********************************************************
**********************************************************
262.17 on Huobi

 

[chriswilmer]

One thing that continues to baffle me about how BitcoinXT was received was/is the broad lack of miner support. It feels like BIP101 has "popular" support(the kind that theymos believes are just upvoting bot armies), and business/merchant support... and some angry/upset developers... but what's the deal with the miners? Especially 21 Inc and KnC Miner... what's their deal?

 

[cypherdoc]

oh so funny as hell:


esp to that clown.
[doublepost=1444880627][/doublepost]@chriswilmer

you can blame it on Garzik. offering such power unnecessarily...

and before writing the code.

 

[chriswilmer]

@cypherdoc

Can you elaborate? I know that BIP100 was his idea... but that doesn't explain why so many miners chose that over BIP101. Isn't Gavin more influential than Jeff?

 

[theZerg]

The more I think about it the more I like the bitcoin unlimited idea. Block size is simply not a consensus issue... but nodes can choose to discourage certain sizes by not relaying.

Note that this works on the low end too. You can not relay a small block if your mempool is huge to encourage miners to build bigger blocks.

So I'm thinking working on it. If I fork will you run it? What should be the baseline? Core or XT?

 

[cypherdoc]

@theZerg

it should use Core as baseline.

i'd run it for sure; under the following conditions. you'd have to identify yourself and hopefully have some decent qualifications to be a lead core dev. someone has to do it. if you could get Gavin to be a core dev that would be even better. he clearly doesn't want the lead role but his support would be invaluable. before doing it, i would also talk to @Melbustus about what he's doing.
[doublepost=1444882252][/doublepost]

@cypherdoc

Can you elaborate? I know that BIP100 was his idea... but that doesn't explain why so many miners chose that over BIP101. Isn't Gavin more influential than Jeff?

100 gives voting power to the miners, which they seem to love.

 

[rocks]

The more I think about it the more I like the bitcoin unlimited idea. Block size is simply not a consensus issue... but nodes can choose to discourage certain sizes by not relaying.

Exactly and this is what has been so dishonest about the debate. It is a debate on the max limit, not on block sizes. Miners are already discouraged from mining large blocks until faster transmit mechanisms are in place (such as IBLT). Large blocks increase the orphan risk.

The reality is even with no limit blocks would still be limited in size, the difference is they would be limited based on economic incentives for miners, not on artificial rules created in a vacuum.

 

[AdrianX]

@cypherdoc

Can you elaborate? I know that BIP100 was his idea... but that doesn't explain why so many miners chose that over BIP101. Isn't Gavin more influential than Jeff?

It's not about influence. It's about power and profits.

BIP100 gives more power to miners to manipulate market with voting.

Here is a simplified hypothetical example: Miners with cheap electricity, rent and labour and a poor internet connection (say the typically Chinese miner today) will be at a disadvantage in a free market when it comes to block propagation when competing with a miner with higher overhead but ultra fast internet and propagation time. (Say a smaller miner on the east cost of Canada)

Each have an advantage in a free market and depending on conditions there will be winners and losers but with BIP100 one has a vote that can undermine the other, and limit block size.

BIP100 gives the majority of miners some control over other miners this break Bitcoin. BIP101 gives miners a free market and control over their own destiny.
[doublepost=1444890902][/doublepost]

Exactly and this is what has been so dishonest about the debate. It is a debate on the max limit, not on block sizes. Miners are already discouraged from mining large blocks until faster transmit mechanisms are in place (such as IBLT). Large blocks increase the orphan risk.

The reality is even with no limit blocks would still be limited in size, the difference is they would be limited based on economic incentives for miners, not on artificial rules created in a vacuum.

Bang on! It's dishonest to say block size is part of the conscious layer. (Otherwise ignoran)

 

[sickpig]

in the meantime btc core version 0.11.1 and 0.10.3 have been released, with *another* interesting anti-spam feature:

The default for the `-minrelaytxfee` setting has been increased from `0.00001`
to `0.00005`.

This is necessitated by the current transaction flooding, causing
outrageous memory usage on nodes due to the mempool ballooning. This is a
temporary measure, bridging the time until a dynamic method for determining
this fee is merged (which will be in 0.12).

(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11
release notes, in which this value was suggested)

a five fold increase for minrelaytxfee default value, not bad for minor release.

note also that this anti-spam mechanism share with its most famous predecessor (max block size limit) the characteristics of being "temporary" and having undesired side effect, as Nicolas Dorier rightly pointed out:

Does it means this change will make every (except OP_RETURN) 600 satoshi TxOut Dust ?

If this is the case, this is a very big change for every colored coin protocols, since every colored coin wallets are using 600 satoshi output for carrying the color. (at least OA)
Is it possible to decouple the minrelaytxfee from the dust definition ?

I understand this is not your priority, but the goal of this PR, I think, is to protect against spammy transaction who does not have enough fees, but it impacts way more than that.

hopefully this change would be less "temporary" than the max block size.

 

[cypherdoc]

Wow, such bullshit.

How long have I been warning that this block size restriction would result in problems for the services that are currently inserting data into the block chain as a result of higher fees? Answer: over a year since I heard of SC's.

Those guys should be pissed off. Guck that shit. I won't be upgrading.

 

[Justus Ranvier]

My nodes are shutting down due to outrageous mempool memory usage. Can't be the only one. We need to merge this deploy new versions now.

No mention of the specs on his nodes. Are they running on RPis?

All of the negative effects this change will have on the entire userbase are nothing compared to this one guy's ability to run nodes without a hardware upgrade.

All the people working on and using Bitcoin in ways laanwj and luke-jr don't care about need to bow to his desire to run a few nodes on the hardware of his choosing. That's how important his nodes are.

Decentralization: some nodes are more equal than others.

Seriously though, going from "I have a problem" to "the entire network has my problem" is probably a natural thought pattern for someone in his position, but it'd probably be good to have a way to get a more objective perspective from time to time.

 

[Inca]

The more I think about it the more I like the bitcoin unlimited idea. Block size is simply not a consensus issue... but nodes can choose to discourage certain sizes by not relaying.

Note that this works on the low end too. You can not relay a small block if your mempool is huge to encourage miners to build bigger blocks.

So I'm thinking working on it. If I fork will you run it? What should be the baseline? Core or XT?

I would run this if we can get a working implementation functioning.

It believe it should be exactly the same as Core (though i hate to say it) but with the max_blocksize code changes changed only.

One problem with XT is that it has other changes (that i don't have a problem with) which have allowed it to be attacked rightly or wrongly as a Hearn / Andreson ego walk.

It seems to me that the economic majority is in favour of scaling bitcoin. The more the small blockers paint us as a minority the more clear it is that isn't the case.

 

[cypherdoc]

261.3 on Huobi

 

[sickpig]

@cypherdoc

Can you elaborate? I know that BIP100 was his idea... but that doesn't explain why so many miners chose that over BIP101. Isn't Gavin more influential than Jeff?

@solex started this https://bitco.in/forum/threads/what-has-been-seen-cant-be-unseen.21/ just to answer your question preemptivly

Unlike BIP101 the BIP100 gives miners extra power, extra control. They like it. Really like it.

 

[theZerg]

re: Bitcoin Unlimited. Implementing Bitcoin Unlimited will likely take me some time but will be interesting... I'm ok with it being off of Core. I want to add optional traffic shaping (it will be important when blocksize increases) and a lot of visibility stuff to the GUI (size of mempool, etc). However, I think you are right about having its essential behavior (P2P protocol and consensus) be exactly like Core except for the "unlimited" changes. This will quiet any naysayers.

WRT doxxing myself, I basically already have. I think the need for anonymity WRT bitcoin is basically gone since most major governments have addressed its legality. However, I'll thank you in advance for not posting my name directly connected to this account to make doxxing nontrival for casual readers -- general internet security practices against nutcases.

 

[majamalu]

Hi guys,

Thanks for all the insights. I keep on spreading the word in the Spanish speaking world:

http://elbitcoin.org/por-que-una-moneda-neutral-y-universal-es-inevitable/ (Justus Ranvier)

http://elbitcoin.org/los-pesimistas-de-bitcoinlandia/ (cypherdoc)

http://elbitcoin.org/podria-fedcoin-ganarle-a-bitcoin/ (Zangelbert Bingledack)

http://elbitcoin.org/bitcoin-y-la-desconcentracion-de-la-riqueza/ (rocks)

http://elbitcoin.org/blockstream-negocio-a-expensas-de-bitcoin/ (Aquent)