Gold collapsing. Bitcoin UP.

[AdrianX]

The Corallo Relay Network (CRN) is sad because it's only a benefit if it is not evenly distributed.

Is my understanding wrong? if a miner has a relative 0.15% of orphaning while other miners have a 1.5% chance then the miner with the lower orphan rate will be more profitable. (obviously global resources are not evenly distributed and a market needs to form in which miners operate. The example given is a post market relative orphan rate.)

So if the CRN is deployed everyone who joins it gets a 1 time productivity boost. and two weeks after the gain has been realized the Bitcoin difficulty adjusts and the individual miners benefit is lost. (they are now addicted to the CRN heroin as they have to take a bigger loss to quit given the time it takes difficulty to adjust)

that said when joining the CRN a miners orphan rate just moved from 1.5% to 0.15% but the collective still find a block every 10 minutes regardless of the orphan rate and everything is fair so long as everyone is using the CRN.

Now if the orphan rate was high and 15% of blocks found were orphaned, then the difficulty would adjust and miners dispirit the high orphan rate and existing infrastructure and expenses would still only find 1 block every 10 minus.

so is my understanding wrong, and if not can someone please explain why bitcoin developers are putting so much attention into reducing orphan rates?

 

[Dusty]

can someone please explain why bitcoin developers are putting so much attention into reducing orphan rates?

I think that the more the orphans, the more hash power is wasted instead of protecting the network, but I could be wrong.

 

[Richy_T]

I think that making further "big gains" would mean placing further requirements on nodes such as canonical ordering of transactions or stricter mempool policies--all of which seem centralizing to me (especially if implemented in a top-down fashion by developers).

GMax has said that x-thin blocks only result in a bandwidth reduction of 12%. To him, that makes x-thin blocks pointless (though never mind the gains from reducing burstiness) but to me, that means it seems likely that the next target for "big gains" are in the other part of the protocol that are responsible for that 88%.

If x-thin blocks, as implemented now aren't cutting bandwidth by 40%, there's work to be done elsewhere in the protocol.
[doublepost=1461096515][/doublepost]

Of course not: the Bitcoin p2p protocol is "a gossip protocol" so each node can get an idea on what tx the other peers has by knowing which one it relays to them and which one they advertise.
But this is important when a peer is "new", for long lived connections all your peers tend to have the same mempool so it's not a really important thing.

Why would you do this though? The RN must know every transaction it has sent to you in order to do its optimization. Any transaction it has not sent to you will not be included in the dehydrated block it will send to you (or must be sent before or with it since it won't know you have it). There is no reason at all to be connected to the p2p network.

Edit: Oh, I guess for blocks you will mine yourself. It still might make sense to only connect to the RN though.
[doublepost=1461096805,1461096176][/doublepost]

I think you are misinterpreting my words: I'm not advocating the RL,

Sorry, didn't mean to imply you were. Just exploring the implications.

 

[freetrader]

@Richy_T :

there's work to be done elsewhere in the protocol

@Peter Tschipper 's Datastream Compression efforts are tackling part of that (although they might not cut things down by as large a figure as you mentioned, but they're a good start):
https://bitco.in/forum/threads/buip017-datastream-compression.1001/

 

[sickpig]

Pull request released for segwit by Peter Wuille. He is certainly prolific

what I call a really simple, straightforward change set. They just had to implement 4 bips (141, 143, 144 and 145):

90 changed files
4,743 additions and 554 deletions

ah I forgot the preparatory work needed and contained in PR #7749

5 changed files
54 additions and 0 deletions

ah sorry one last thing I forgot, they chose to postpone BIP 142 because they though it was too much work. funny, isn't it?

 

[Richy_T]

I'm thinking that the nature of the gossip network is likely the issue. I suspect that there's a lot of redundant chatter going on that could be cut quite a lot with some clever scheming, possibly some of it similar to how x-thin knows if the target node has a transaction and possibly some of it clever leafnode schemes. How about x-thin sub-blocks (possibly batch low-fee transactions more)?

 

[AdrianX]

I think that the more the orphans, the more hash power is wasted instead of protecting the network, but I could be wrong.

I think that's a fallacy. maybe you can elaborate a bit, but here is my 2 satoshis worth.

What protects the network is not exactly the hashrate but the economic expense in producing a competing hashrate, and the incentive to cooperate as it's more profitable to mine than to forgo that income to go against the network. The existing hashrate has value of $14,000,000 at the moment. if it was 1.5% less would the network be vulnerable? I can't see why.

But then again any hostile miners would have the same relative orphan risk to mine against the network, by contrast the relay network is an attack as it makes relative hardware investment more effective against those who don't use it. but if it couldn't exist and orphan rate was higher miners would seek to minimise orphan rate with smaller blocks and an attacker would have to compete on a level playing field.

 

[Richy_T]

Yes. In a way, every hash which doesn't produce a block which makes it permanently into the main chain is "wasted" in that it produces no profit for the person doing the mining.

Once you take a different view of "wasted", it's the same for orphan blocks as any other non-mainchain-block.

 

[Norway]

Google this to penetrate Wall Street Journal's paywall:
ETFs’ ‘Spider Woman’ Argues for a Bitcoin Fund

Is this a hint that the bitcoin ETF is finally on it's way?
[doublepost=1461102722][/doublepost]They also published this today:
http://blogs.wsj.com/moneybeat/2016/04/19/is-bitcoin-becoming-more-stable-than-gold/

 

[Peter R]

I think that the more the orphans, the more hash power is wasted instead of protecting the network, but I could be wrong.

Approximately speaking, if the orphan rate were 1% then network difficulty would be approximately 1% lower than it would be if the orphan rate were zero. In my opinion, whether the difficulty is X or X +/- a few % is a rounding error. [EDIT: plus @AdrianX's great point about the cost of attack]

AKAIK, the "reason" to keep global orphan rates reasonably low is because a miner with a large hash rate has a small theoretical advantage over a miner with a small hash rate. A miner controlling 30% of the global hashrate will earn slightly more than 30% of the total revenue, assuming all miners suffer the same orphan rates. The size of this advantage depends directly on average orphan rates.

You can see this by first noting that any miner who solves two blocks in a row, had a "head start" on the second block and thus a profitability advantage for that particular block (he got to work on it immediately, while everyone else started a bit later wasting some of their hash power in the meantime). The chances of solving two blocks in a row for a 30% miner is 0.3 x 0.3 = 9%. The chances of solving two blocks in a row for a 3% miner is only 0.03 x 0.03 = 0.09%.

Notice the non-linearity!

Although the 3% miner has 10% the hash rate of the 30% miner, he has only 1% the chances of solving two blocks in a row. Finally, the higher the average orphaning rates are, the larger each "head start" is on average. Thus, larger miners benefit from the "two blocks in a row" head-start disproportionately to their hash power and the head-start gets bigger the higher orphaning rates are.

 

[lunar]

Well said.

 

[Norway]

@lunar
Let's call banks printers from now on
[doublepost=1461104070][/doublepost]Gotta go to bed now. I have a meeting to get investors tomorrow morning

 

[lunar]

@Norway

Banks = Fax machines
bitcoin = Email

 

[AdrianX]

ftfu
Banks Fiat = Chinese whispers
Bitcoin = Email

 

[lunar]

@AdrianX

Whatever it is ? ... It's going UP

 

[cypherdoc]

Way over the top now:

 

[johnyj]

No change of signature scheme will save you: the fact is that if you have some bitcoins on the blockchain before the fork, you have the private keys to control them.
And if you have the private keys you can sign in whatever new scheme you come up in every chain. If you can't sign them then you do can't control your coins, and hence you was not owning them before the fork.

Having the private key does not mean that you can spend the utxo on a specific network. The Pay to Public Key Hash function today only direct certain amount of coins into an address that is corresponding to your private key, but to spend the coins in that address, you need the new software to authorize the spending action

For example, in classic software you can design a rule to allow only the most simple form of 1 to 1 transaction for pre-fork utxos, so that once it is spent on classic chain, the classic software will immediately spend the same utxo on the other chain

And this design will make the sell pressure on classic chain much less, since you lose both coins when you sell on classic chain

 

[freetrader]

@johnyj:

you lose both coins when you sell on classic chain

Sounds like that design would take away financial choice from the user.

in classic software you can design a rule to allow only the most simple form of 1 to 1 transaction for pre-fork utxos, so that once it is spent on classic chain, the classic software will immediately spend the same utxo on the other chain

Introducing such a design would constitute central planning (on a small scale) in my view.
It'd be like the government deciding that when you sell your bike, your car also gets sold.

 

[steffen]

What we were talking about is involuntary reproductions of transactions across forks by means of bridge nodes doing more or less advanced translation (none if the transactions remained identical).

Here is a possible recipe for secure moving of pre-split funds to the good chain after a split:

1. The wallet you have your pre-split funds/keys in is either following your preferred chain or the chain you do not prefer. Make a backup of your keys and restore the keys to a wallet following the other chain. You should now have an identical number of coins in the two wallets.
2. Set up two more wallets (one for each chain) and generate new post-split keys in these two new wallets. Create backup of both new keys. Both the two new wallets are empty.
3. For each of your old wallets with funds prepare a transaction which sends the entire content of the wallet to the new empty wallet on the same chain. When you are ready with both wallets press send in both wallets at the same time. Most likely all your funds will move to your two new wallets with post-split keys. Be patient and check a blockchain explorer if you are unsure what happened. If someone managed to act very fast and broadcast one of your transactions to the unintended chain the funds will still be yours but you will have to restore keys to the new wallet(s) that did not receive any funds. The keys to restore are the keys from the other new wallet with post-split keys.
4. When all your funds are secured with post-split keys that only exist on one chain any further transactions will automatically be invalid on the other chain. You can therefore now securely sell your cripplecoin on an exhange.

 

[freetrader]

@steffen : I like your procedure and think it would work.
Hopefully someone would offer the general public an easier way to perform this due to the complexity of the operation. One of the difficulties is in connecting to different fork networks from a single machine - one needs to sequentialize operations which makes step (3) "press send in both wallets" a little difficult. Not something the ordinary user would get right.

To complicate matters, there could be more than two chains involved...
What would be very useful is there was a "splitter" service, sort of the opposite of a mixer, which could reliably separate the coins for users, performing as many iterations as needed to get it right. Of course that's a tremendous can of worms