Gold collapsing. Bitcoin UP.

[solex]

The problem here is that Orc guardians of the Great Dev-List Entry Gate are Kanzure and BtcDrak who are entranced by the power of the One MB Ring. So, they will put messengers from afar to the sword even though they carry wise advice for the people inside. Advice that would in fact be of real benefit, but is silenced to their own detriment.

Edit: maybe the people inside saw the messenger and might just listen.

 

[Zangelbert Bingledack]

J. Toomim apparently had a huge discussion with Core on their slack channel yesterday. For some reason the post was downvoted in /r/btc so I didn't see it until now.

https://bitcoincore.slack.com/messages/general/

 

[solex]

Adam Back @jtoomim: it can be that you might find bitcoin unlimited interesting. they try to select consensus rules dynamically by votes somehow jtoomim: and parameters.
Jonathan Toomim @elliotolds: I'm not sure the people here are ready for the answer to that question
Adam Back jtoomim: if i understood by full node count or something
Jonathan Toomim @adam3us: yes, it's an interesting idea. it needs to be evaluated more, and maybe tested.
Jonathan Toomim @adam3us: no, not by full node count
Adam Back they seemed to have a lot of ideas but i couldnt quite see that it was practical yet.
Jonathan Toomim the basic mechanism is that you don't have a single hard limit on the blocksize
instead, you have a graded limit on size
Adam Back jtoomim: i did ask but there were many people and they all had different ideas so it was a bit confusing as to which proposals were validated and which what-ifs
Jonathan Toomim or several limits that exist for blocks at different depths
so if you had a block that was say 10% larger than your configured limit, you might accept it if it were buried 10 blocks deepbut if it's 50% larger, maybe 15 blocks deep etc which makes miners who mine blocks larger than the "schelling point" have greater orphan risk and emphasizes their motivation to keep blocks below what is acceptable for propagation and other miners

@Zangelbert Bingledack
thanks for highlighting that channel. I have just realized that BU needs to be seen to be developing a Schelling point or an emergent limit, or it will remain a curiosity.
First step is making use of the user-agent / BUIP005 info in a graphical and public manner.

 

[Zarathustra]

r/NorthKorea collapsing - r/btc up!!

https://www.reddit.com/r/btc/comments/41iavc/rnorthkorea_collapsing_rbtc_up/

 

[solex]

@Zangelbert Bingledack
Jeez. The Team Directory gives the email addresses of 400+ notable Bitcoiners. That's a real security lapse. Hmmm.... Maaku is the only one deactivated. Wonder why.

 

[cypherdoc]

Explain

 

[kyuupichan]

I posted my paper up on reddit...


...getting lost in the coinbase mess I think.

theZerg, so you're the ferret-not-in-Japan; I'd wondered for such a long time who that was (and I'm not the only one)

 

[sickpig]

@cypherdoc

to subscribe to bitcoin core slack, providing a valid email is mandatory.

such info is available and public to all channel subscribers.

so if you registered with a private email address, such address is not private anymore.

fwiw the same applies to bitcoin classic slack.

 

[cypherdoc]

Well here's my response to Mark Friedenbach's Olympic-tier handwaving in defense of his position.


A very slightly modified comment was instantly deleted from the /r/Bitcoin thread, probably because I said Mark's mental model appears to be fuzzy, which I guess they count as "insulting a Core dev." (EDIT: Weird, it was deleted but now it's at -2. Maybe it was reinstated?)

That thread is so sad. So many people who don't get it. And probably a lot of gvt provocateurs.

 

[sickpig]

Anthony Towns has just updated is calculation wrt SegWit gain:

TLDR:

1.7MB effective block size is a better estimate than 1.6MB for p2pkh
with segwit. 2MB for 2/2 multisig still seems accurate.

Additional post-segwit soft forked script improvements can improve
the effective block size for p2pkh txns from 1.7MB to 1.9MB, and for
2/2 multisig from 2MB to 2.5MB/3MB.

post-segwit soft fork improvements == mainly moving to schnorr sigs.

Unrelated but very interesting initiative:

http://loophole4all.com/
https://paolocirio.net/press/texts/text_loophole4all.php

 

[Richy_T]

if you're an old node and you receive a SW tx, you will see it as a non-std tx and will ignore it (no validation or relay) until it is accepted into a block. this is b/c SW pushes 2 items onto the execution stack instead of one.

Why does it accept it when it is in a block. I thought blocks were validated too?

 

[albin]

IsStandard() only affects the client relay, it's not a consensus rule for validity.

 

[Erdogan]

Bitcoin Classic was mentioned in this BBC piece - but not Bitcoin Unlimited - hmmm.

http://www.bbc.com/news/technology-35343561

 

[theZerg]

QUOTE="kyuupichan, post: 9945, member: 222"]theZerg, so you're the ferret-not-in-Japan; I'd wondered for such a long time who that was (and I'm not the only one)[/QUOTE]

No he just replied to my post

 

[Richy_T]

IsStandard() only affects the client relay, it's not a consensus rule for validity.

That seems odd

 

[cypherdoc]

@Richy_T

for the same reason, this is how f2pool was able to create it's single tx, self constructed, 1MB, multi-input, UTXO clearing, 25 sec, On^2 sigops, non std, OMG block and get it propagated across the network that just happens to stall every discussion about no limits or high limits.
[doublepost=1453135525][/doublepost]what's the fastest way to search this entire thread for a keyword?
[doublepost=1453135619][/doublepost]

After Saruman retreated into the heart of Mordor in December, and after Unlimited and later Classic took off, my hunch was that he'd return and back-pedal:

"The Bitcoin Core developers recognize that Bitcoin is ultimately governed by its users; although we stand behind our scaling roadmap, the community has spoken. For this reason, we will be increasing the block size limit in Core to 2 MB in the spring."

Instead, he and his orcs dug their heels in deeper.

We're now competing for the hearts and minds of the non-fanatical. By engaging #bitcoin-wizards--and receiving clear statements like this from maaku--the other participants can see the childish pettiness of Blockstream's position. They might ask themselves:

"Am I really going to leave Bitcoin just because I'll be issuing pull requests from a different repo (or perhaps more than one repo)?"

"If 1 MB was a magic number anyways, is it worth risking my reputation defending this arbitrary line in the sand against the overwhelming support from the community?"

how can maaku7 justify being a core dev of Bitcoin when he believes in Freicoin economics?

 

[cypherdoc]

J. Toomim apparently had a huge discussion with Core on their slack channel yesterday. For some reason the post was downvoted in /r/btc so I didn't see it until now.

https://bitcoincore.slack.com/messages/general/

was that in the "implementation" channel?
[doublepost=1453136954][/doublepost]

post-segwit soft fork improvements == mainly moving to schnorr sigs.

ahem, somebody around here said the same thing a short while back.

for those Towns calcs, those are just the "message data" sizes for blocks, right? what are the size totals when you include the witness data? link?

 

[cypherdoc]

lukejr trolling the Classic Welcome channel. what a clown.
[doublepost=1453139113,1453138472][/doublepost]OPTION ONE - Change the blocksize upper limit to two megabytes. One line of code for the constant, about ten LOCs for activation trigger logic. Requires upgrading of a majority server software.

OPTION TWO - Introduce Segwit. About 500 lines of new code, of which at least 100 in the hypersensitive consensus code. Requires upgrading a majority of server software and all client/wallet software and client/wallet hardware, especially those needing to pay money to an arbitrary address (as Segwit introduces a new type of address that both sender and receiver must handle).

When proponents of Core's scaling tell me that Option Two here is the better because it's safer, and I try to comprehend that statement, I am either utterly insane or the statement is the equivalent of "black is white and up is down". It's just not completely counter to all experience in software engineering risk management, it's so far out it doesn't reflect sunlight anymore.

https://www.reddit.com/r/btc/comments/41ipkd/some_advice_for_everybody_at_this_point_in_time/
[doublepost=1453139585][/doublepost]The three use cases I referred to were;

• remittance,
• credit card replacement, from the merchant's PoV,
• credit card replacement, from the payer's PoV.

 

[rocks]

Quick update on the total hash rate behind Bitcoin Classic. There is over 80% support using today's hash rates.

The current Bitcoin Classic declared support is 57.5% composed of:

• Bitmain/Antpool - 29% (4 day average at blockchain.info)
• BitFury - 16% (4 day average at blcokchain.info)
• BW.COM - 6% (4 day average at blockchain.info)
• KnCMiner - 5% (4 day average at blockchain.info)
• HAOBTC.com - 1.5% (claimed 13K Th/s of current estimated 900K Th/s)
• Genesis Mining - ?
• Marshall Long - ?

Interestingly Antpool jumped up a few points over the past four days, while BTCC dropped a few to 13%. Not sure if that is due to variation or miners voting with their feet.

F2Pool stated they want a 2MB now and "welcome" Classic. But they also said they will be upgrading to 0.12 at some point, which is core. They also say they will be dropping FSS-RBF after upgrading and may not support opt-in RBF. Overall positive but their statements are a little contradictory.

With F2Pool, the 2MB fork has 77.5% support

• F2Pool - 20% (4 day average at blockchain.info)

Slush has been quiet, but given their support for XT I'd assume they are behind Classic. That would bring us to 80.5%

• Slush - 3% (4 day average at blockchain.info)

Here is the communication from F2Pool. Again it is a little contradictory IMHO .

"Policy change announcement: We support the hard fork effort to increase the max block size to 2MB. Seg-wit may be deployed together in this hard fork if it can be ready in time, or it can be merged later. Non-controversial features in the hard fork wishlist, if it does not delay the hard fork process, can be deployed at the same time. The hard fork should be implemented in Core, eventually. “Bitcoin” Classic, which despite was born on the same day that XT dies, is an attempt that could make the hard fork happen sooner. We welcome Classic. We are going to cease support for FSS-RBF after upgrading to version 0.12, some time in the next few weeks. We may not implement the opt-in RBF feature We believe that we should do everything we can do to make 0-conf transactions as secure as possible. We do not believe the concept of fee market."

 

[cypherdoc]

if you want to influence f2pool, get involved here:

https://bitcointalk.org/index.php?topic=700411.new#new
[doublepost=1453140946][/doublepost]Hearn f/u

https://medium.com/@octskyward/a-small-followup-aa399a83acbb#.tewwy94bp
[doublepost=1453141390,1453140577][/doublepost]hilarious, @Peter R pounding the Wizards:

https://botbot.me/freenode/bitcoin-wizards/