Gold collapsing. Bitcoin UP.

[cypherdoc]

remember how i think the USD has changed character and is now following the stock mkt? here's $DXY plotted against the $DJI. note the red arrow where i think things changed. that's a big deal and if you need a "reason" as to why this might be, consider this. if we're going into another recession, what is the Fed most likely to do? ans: print:

[doublepost=1449683336][/doublepost]

GBTC hit a high of $72.5 today for roughtly $760 per BTC.

The twins need to get that ETF out.

I also don't understand why GBTC is allowing this premium. They could easily buy coins on the open market, create GBTC shares from those coins and sell those GBTC shares for a huge premium. That's what most closed end funds do when there is a large premium on the underlying asset.

holy begeezers-->Gold collapsing. Bitcoin UP:

 

[sickpig]

it seems we have a new member

welcome @Gavin Andresen

 

[cypherdoc]

Welcome Gavin!

 

[awemany]

@Gavin Andresen: Hi and welcome!
Your blog posts rock, as always

(Oh, and now I feel under surveillance. Where should I go with all my zesty mean remarks about the core developers? )

 

[chriswilmer]

Yes, I think we should try to not be mean!

 

[cypherdoc]

@solex

so you like SW? assuming you say yes, what about some of the moral hazard i see:

1. allows script to be changed via soft forking-the negative view would be that old nodes are unable to object
2. Wuille tx fee discount for SW
3. is a political means to forestall a block increase
4. prolongs the central planning ideology of core dev

the reason i like 101 of BU instead or even concurrent with SW is that it will help redistribute mining away from China and allow growth of Bitcoin by allowing ROW to leverage it's bandwidth superiority. and given Wang Chun's childish behavior, this would be a good thing.

 

[solex]

@cypherdoc

I like SW as it is a major design improvement (though it probably should be done with a hard-fork).
However, your points are valid. While the software is good, it comes within a political context. It does help Core drag their feet on the block limit, and prepares the ground for LN, and fits with the Blockstream strategy to push volume off-chain (where they will get a steady fee-income).
I don't like them monkeying with the fee market. This should be a demand/supply equation as Peter_R always says.

I agree that we need BIP101 first, then IBLT, and then SW.
Core are doing things in the wrong order to suit their agenda.

 

[Justus Ranvier]

Oh, and now I feel under surveillance.

Did you really think you weren't already?

 

[awemany]

@Justus Ranvier :

Of course not!

However, there is still a sense of a certain community correlating with a certain forum.

Though if you think about it from a high level perspective, the set of all internet forums is just one big distributed data store so that doesn't really make sense.

 

[Inca]

Gavin's blog shows he believes segwit should be implemented via hard fork IMO.

Either way the scaling bitcoin conferences have failed to produce a solution - quelle surprise.

I think it is likely after the segwit hullabaloo calms down that the ecosystem will once again drive renewed calls for raising the block limit. Maxwell et al will then probably then be forced to implement a 'kick the can' fix to bump it up to 'safe' 2mb limit or be forked, whilst they spend the next two years attempting to mainstream LN.

Maxwell's worst nightmare would be the actual Satoshi to come out of the woodwork and side with XT or a general scaling solution via blocksize increases. The oft spouted meme from blockstream's useful idiots such as Gibbs or brg44 is that Satoshi has left the project and is irrelevent (except when they used that obviously fake Satoshi email as a badge of support of course- lol).

If the last 24 hours has shown anything it is that Satoshi could easily help right the listing ship if the project is seriously at risk of failing. A single cryptographically proven pgp signed key or signed private key could stop Maxwell in his tracks - and he knows it.

EDIT: welcome gavin!

 

[rocks]

@Inca
"Gavin's blog shows he believes segwit should be implemented via hard fork IMO."

The reason (I think ) is without a hard fork that forces all clients to upgrade and become SW aware, SW inadvertently creates a red / black coin situation, which is very bad.

With the soft fork path we will end up with some set of coins usable by everyone (coins on the main chain), and another set of coins only usable by SW upgraded clients (coins that have previously been sent with SW).

This is a dual-tier BTC situation, with some coins being more valuable than others. You could even imagine some exchanges starting to set different prices for them or merchants starting to set different prices based on on/off chain coins. Until the system fully upgraded I personally would never consider accepting SW inputs in such a situation, and if a pricing gap emerged I think most would take the same view which creates a feedback cycle.

It's also why I'm starting to think SW will not be a widely used feature even if they force it in. No one is motivated to use it until everyone else starts to use it. Until then you are transferring coins into a system only a sub set of Bitcoin users can use. Why do that?

 

[Inca]

@rocks:

Exactly why a soft fork implementation of this is a bad idea.

I view the current Core developers as caretakers of the codebase and the problem with that is that the incumbents see themselves as expert programmers and cryptographers who must add complexity and demonstrate their intelligence constantly to one another and the community by fiddling and tweaking things without addressing the giant elephant sat in the room.

What is needed is pragmatic leadership.

 

[cypherdoc]

@IncaSW inadvertently creates a red / black coin situation, which is very bad.

that's a great point that has pretty big implications.

yeah, the complexity created by SW for little gain shouldn't be attempted until we see the consequences of changing a single constant in the code facilitating bigger blocks. even if they were bad, fixing it would be simple solution.

devs gotta dev, another meme i'm hated for.

 

[rocks]

@Inca
Fully agree.

It also might tremendously backfire on them and damage their mindshare in the community.

Imagine if you happily upgraded to Greg's super cool new scaling method. You get excited to use SW and receive your first SW coins. So far so good, everything worked fine, the transactions worked and your wallet shows the coins.

You then decide to spend them or sell them. But the exchange or merchant post a standard BTC address only. You ask for them to post an address that can receive SW transactions. They reply either no or here is a SW address but to do values your coins less. Now you realize you just lost money and the SW coins are locked into SW only users. Now things are not so good.

So you decide to try to reconvert your coins back to the main chains. But you then find out this is not possible because the main chain is for non-upgraded clients and they do not recognize your SW coins. You then realize your coins are forever locked into a SW only world unless you find someone willing to trade with you for a significant cost. Now things look very bad.

This soft fork path might backfire to the extent that people realize the need to keep coins on the main chain and to never move them off. Later when LN or SC come around there will be a lot few people willing to try.

 

[cypherdoc]

sounds to me like Eugene Kaspersky is bad at game theory:

http://forklog.net/eugene-kaspersky-cryptocurrency-is-a-most-brilliant-invention/

 

[Peter R]

@rocks: can we verify that what you're saying is correct, because that was my hunch as well (but I haven't thought about it enough). If SW is deployed as a soft fork, people might move coins to SW addresses and have the coins "stuck" there should a significant portion of the network not be interested in upgrading. Worst case would be if Core implements SW, people begin doing SW transactions, but then we fork away from Core and drop support for SW for some political reason. It seems those coins would be permanently lost.

Can someone confirm?

 

[solex]

No, there isn't a red/black coin problem.
When it comes to spending outputs all the network cares about is that you have evidenced possession of the private key that can "unlock" them. It doesn't matter how the previous owner sent them, i.e. whether their signature/script is on an current style tx, or segregated into a witness data area. (in the latter case an un-upgraded node is fooled into thinking "anyone can pay").

 

[Badbeat]

Here is the twitter feed in pics from the alleged Satoshi

 

[molecular]

@awemany - "He still clearly doesn't get it. It's up to the miner to decide cost for a transaction, not pwuille."

Yes, exactly. That's essentially the key folly in core-dev's approach these days. Unfortunately the Hong Kong conf was a terrible outcome for this viewpoint since most miners essentially refusing to exercise a vote because they're ignorant just re-enforces core-dev's impulse to specifically architect everything from the start.

We need more miners/pools that are willing to implement their own code, and we need them soon.

Well, you heard the guy on the rightmost side of the miner panel. The one with the balls almost hanging out? He said they pretty much use vanilla configuration (let alone code) because of fear of being incompatible somehow and losing revenue. My takeaway: miners don't really give many shits about anything except their (fiat) revenue... who can blame them and shouldn't it be like that? I guess so... but isn't it kind of sad: those guys have so much power and aren't willing to use it out of fear of losing some money?

 

[rocks]

@solex
OK, then my understanding of how SW works is flawed then. I haven't had time to dig too deeply into the technical details. I thought SW moved part of a transaction's data packet to the side block and then attached that with a hash. But that would mean that to understand the UTXO for the received SW transaction a client would have to be upgraded.

For non-upgraded clients that only recognize main chain transactions and only download the main chain, how can a SW transaction be later validated as a valid UTXO that can be spent?