Gold collapsing. Bitcoin UP.

[cypherdoc]

they could do that but they'd have to pick an implementation and also announce that so full node operators could prepare to assist.
[doublepost=1454605794][/doublepost]GBTC turning the corner:

 

[cypherdoc]

Classic ties #BU nodes already:

 

[Zarathustra]

Just XT 0.110E Nodes are compatible with the 2MB hard fork, right?

 

[cypherdoc]

not sure but it's too bad we can't join forces. such minimal differences at this pt since 101 is off their table.

 

[cypherdoc]

great article:

That is akin to burdening horses with engines in the name of technological innovation: the approach would only slow down the horse and alleviate none of its problems.

In contrast, the bitcoin network was born from the blockchain design two months after Nakamoto presented the technology. To this day, it has been operating uninterrupted and growing to more than $6 billion worth of bitcoins. The blockchain was the solution to the electronic cash problem. Because it worked, it grew quickly while Nakamoto worked anonymously and only communicated curtly via email for about two years. It did not need investment, venture capital, conferences, or advertisement.

http://www.americanbanker.com/bankthink/blockchain-wont-make-banks-any-nimbler-1079190-1.html

 

[Peter R]

Thought of the Day

"A hard fork is just a soft fork is reverse."

To explain, imagine that we were soft-forking from a 2 MB block size limit to a 1 MB limit:

Core would say that this only requires majority hash power--that the nodes could upgrade later because if they accept 2 MB today they would have no problem accepting 1 MB tomorrow.

If we imagine a hard fork as the same process in reverse, it logically follows that the nodes could upgrade earlier. They can increase their limits to 2MB (or higher) today.

If we want to get bigger blocks, the first step is for nodes to be willing to accept bigger blocks TODAY. This "coordination stuff" requiring 750/1000 blocks that Classic is trying to do should be left to the miners.

 

[solex]

Just XT 0.110E Nodes are compatible with the 2MB hard fork, right?

Yes. Because the Classic block version is incremented then all the old XT nodes will keep observing the 1MB limit by not seeing the 750/1000 trigger.

 

[lunar]

Bitcoinj Maintainer Andreas Schildbach: Segregated Witness worth the Effort

When it comes to the block size topic, I think Segregated Witness is not a solution at all. In the most optimistic estimations, Segregated Witness offers an added 1 megabyte per block. I think that in practice, actual usage will grow slower with Segregated Witness compared to a 2-megabyte hard fork increase, as it requires all wallets and services to upgrade. The space optimization is nice, but just a bit of sugar on top of the other advantages. We will need to see more to achieve real scalability.”

“Blocks are full, and I don’t agree that a hard fork solution would be short notice. We’ve been discussing this issue for years now! I would prefer we roll out a hard fork,

Seems another dev is reassessing the scaling plan. Perhaps intellectual honesty and reasoned debate will win out after all?

 

[rocks]

Quick question regarding SFSW that I think was discussed before.

My understanding is non-upgraded nodes see SFSW transactions as unprotected transactions with no signature required to spend. Is that understanding correct? If not how do non-upgraded nodes see SFSW transactions?

 

[cypherdoc]

non-upgraded nodes see SFSW transactions as unprotected transactions with no signature required to spend.

correct, old nodes only see these new tx types as data with no sig, ie, ANYONE_CAN_SPEND. core dev logic goes like this though, "since these aren't the old nodes tx's anyways, it won't hurt them to just relay them".

Instead, the outputs do not push these scripts that we required to be satisfied, they would be encapsulated, it would be pushed as a piece of data. This allows us to, this effectively to every node, and every node not using this system, it's an ANYONECANSPEND. It's just an output that pushes data on the stack, the output doesn't do anything else. It's ANYONECANSPEND.

http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

 

[go1111111]

a+b/4<=1mb would only be the case of (let's call b=b1+b2) a+(b1+b2)/4<=1mb which would only apply if b2=b1*3

I'm not sure what you're doing here, but Mengerian and Cypher are correct. The formula is a+b/4<=1MB where 'a' contains some of the data for transactions with witness data in 'b'.

Wait so I had the impression that the non-witness portion always would be capped at 1MB regardless, the total size of the witness would be capped, and the 1/4 coefficient had to do with discounting witness data size in terms of fee/kb for miner tx selection logic? Is this not correct?

Anything you need to understand about SW's effect at a high level can be understood by looking at a+b/4 <= 1 MB.

If we assume miners aren't worried about propagation latency, then they will rationally give require witness data in transactions to be paid for by about 1/4th the amount of fees they'd charge for non-witness data. If they're worried that making their blocks too large will increase their orphan risk, then they'll give less of a discount to witnesses. The 1/4th discount isn't just some fee policy that Core is recommending to miners. It flows from actual miner incentive given the above equation.

 

[rocks]

correct, old nodes only see these new tx types as data with no sig, ie, ANYONE_CAN_SPEND. core dev logic goes like this though, "since these aren't the old nodes tx's anyways, it won't hurt them to just relay them".

Instead, the outputs do not push these scripts that we required to be satisfied, they would be encapsulated, it would be pushed as a piece of data. This allows us to, this effectively to every node, and every node not using this system, it's an ANYONECANSPEND. It's just an output that pushes data on the stack, the output doesn't do anything else. It's ANYONECANSPEND.

http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

Thanks

OK, if that is the case then I am baffled at how anyone could think SFSW is a good idea. There is no mechanism with the soft fork upgrade path to verify that a majority of hash power is SW compatible, and without a majority of hash rate that is compatible SW users are exposed to theft of coins since SW transactions are unprotected if a majority of the hash rate does not support SFSW.

If I was a miner such as Antpool with close to 30% of the hash rate, I would seriously look into the possibility of down-grading to a non-SFSW compatible client to push the majority of hash rate into the incompatible group, and then transfer SW transactions to myself. If you can flip 30% of the hash rate that is probably enough to flip to the majority to not support SFSW.

Transactions are suppose to be fully trustless but SFSW relies on trust in miners to run updated code to protect transactions. No one should rely on trusting others yet SFSW relies on trust, this seems just plain wrong.

Or am I missing something and it is not as bad as this?

 

[cypherdoc]

@rocks

the SWSF code requires 95% acceptance from miners, afaik.

 

[rocks]

@cypherdoc
OK thanks that makes sense. But how is the 95% threshold communicated?

Also, what prevents 46% of the hash rate (+5% non-SFSW makes 51%) from indicating that they accept and support SWSF but then switch to non-SFSW compatible behavior after the threshold has been activated? It seems relatively easy and very tempting for 2-3 pools to get together and mine a non-SWSF chain in order to sweep transactions even after activating SFSW.

In seems instead of only having to trust in the strength of your private key (today's behavior) with SFSW you also have to trust miners to behave honorably.

 

[cypherdoc]

signal support thru the block flags like they do now.

miners could always collude like this. but they won't for the same reasons we always give around here that they won't want to destroy confidence in Bitcoin and therefore their HW investment and the price. if they flag it, they should support it.

the only way to evaluate SWSF is to understand the math & economic game theory behind it in terms of the same positive feedback motivations we always use. for instance, if 1MB stays enforced and SWSF goes thru, users might have an incentive to use LN for cheap tx's as they get diverted away from mainchain due to high fees. otoh, i'm not sure miners will want to see this b/c the more a block gets filled with LN multisigs, the bigger the block gets and the greater the chance for orphans from blocks created btwn 1-4MB.

and, i think, the less tx fees they will make from having to discount from the b/4 component(can someone confirm this?).

 

[bracek]

@cypherdoc
cypher, would you give us a short comment of this video,
what caused this recent change in all the graphs

 

[cypherdoc]

 

[cypherdoc]

I'm not sure what you're doing here, but Mengerian and Cypher are correct. The formula is a+b/4<=1MB where 'a' contains some of the data for transactions with witness data in 'b'.



Anything you need to understand about SW's effect at a high level can be understood by looking at a+b/4 <= 1 MB.

If we assume miners aren't worried about propagation latency, then they will rationally give require witness data in transactions to be paid for by about 1/4th the amount of fees they'd charge for non-witness data. If they're worried that making their blocks too large will increase their orphan risk, then they'll give less of a discount to witnesses. The 1/4th discount isn't just some fee policy that Core is recommending to miners. It flows from actual miner incentive given the above equation.

bolded is what they will do.
[doublepost=1454649297][/doublepost]but why go there now when they can go straight to 2MB blocks and higher fees immediately? we'll support them.

 

[Richy_T]

I'm not sure what you're doing here, but Mengerian and Cypher are correct. The formula is a+b/4<=1MB where 'a' contains some of the data for transactions with witness data in 'b'.

No, I still don't see it. Do you have a citation?

Edit: This agrees with what you say. Though that still doesn't really make sense to me.

https://bitcoin.org/en/bitcoin-core/capacity-increases-faq

I'll definitely be doing some more reading tomorrow.

Edit2: On further thought, that faq is likely accounting bullshit. It starts talking about 2 and 4 mb blocks. But with a soft fork, the 1MB *actual* block limit is still in place. (Edit2b: Perhaps this is what Cypher was referring to since... no, never mind, it still makes no sense).

Edit3: The "current proposal" links to a fucking youtube video? Are these people illiterate as well as innumerate?
[doublepost=1454655885,1454654724][/doublepost]OK, I tracked it down and see what go1111111 means. I might be the only one who didn't get it but I'll lay it out in case it helps anyone else because it's so fucking stupid, it's almost incomprehensible.

So towards the blocksize limit, is counted 1)The normal transactions that go in the block 2)The part of the segwit transactions that have to go in the block and 3)1/4 of the segwit transactions that aren't in the block at all

WTF indeed.

Linky:
Edit: Still having trouble believing that is the plan. What is the logical reason for the /4 ? Why are we being asked do swallow this with such poor information and communication?

 

[tynwald]

The most amazing thing is that people believe that Adam, Greg and so forth won't drop Bitcoin like a hot potato as soon as it is profitable for them to do so.
<snip>...

All that is needed a sufficiently useful side chain to be developed that can accept all of Bitcoin being siphoned off via a Peg. Then Bitcoin would discarded as the network value had been transferred to a "better" place - at least better for BS investors .