Gold collapsing. Bitcoin UP.

[freetrader]

Yesterday on Twitter I saw some tweets about the rise of Bitcoin to > 10K levels.

One of them read "It only took 400M of monopoly money" (implying USDT).

Another concluded with something like "Congratulations, you made Ben Bernanke proud."

What I'm asking myself now, is whether the ends justify the means for some people whom I've sort of respected up to now, and who haven't spoken out about the rather obvious manipulation of the markets.

I get that it's a happy thing that Bitcoin is sticking it to the naysayers and central bankers right now. But Bitcoin is still just a gnat -- though becoming a very annoying one -- and we should ensure it grows up on a solid foundation.

I sure hope that those who printed the monopoly money - if that is the case as the evidence suggests - ensure it is backed up, real quick. If that happens, it would be a pleasant surprise.

 

[adamstgbit]

@freetrader

news of tethers complete insolvency is probably exaggerated IMO.
i mean various exchanges have been reporting high tether volume...
i bet tether is not-liquid & only a little bit insolvent, they might hold value in BTC or ETH or other coins poeple are trading in for tether , as backing.
but who knows... could be a total scam

 

[wrstuv31]

How about block and report?

@hari

 

[adamstgbit]

the most prevalent thought on the avg bitcoiner's mind today is:
"bitcoin has officially broken the physiological barrier of 10K, sky's the limit !"

this could get really scary...

 

[satoshis_sockpuppet]

I'm really excited what accident will pop the bubble this time.. Does Bitfinex has enough volume to pop the bubble when they go bankrupt or get hacked again?

Never seen as much Bitcoin talk in the mainstream media before. Looks like everybody and his mama is buying in now. We'll see how many of these people will cry for daddy government to restrict cryptos, when they'll lose thousands of dollars in a few hours...

I decided to stay with my current BTC/BCH ratio although it is very tempting to change some more BTC into BCH these days... But I wouldn't want to stand on the sidelines if they manage to push BTC close to 100k or so..

Oh, and it's funny how none of the new buyers are actually using Bitcoin. We should see more transactions with more people buying in. But most are just buying a slot in Coinbases database and don't own a private key...

What's up with changing the time between blocks? This seems like breaking of the 10 minute canon. Am I missing something?

AFAIK it's about reducing the variance. Which isn't really a problem imho but also nothing bad to "fix". (I'd rather have devs work on other stuff.. But who am I to tell people what to work on voluntarily )

Address change all over again?

Also not necessary imho, but apparently Bitpay wanted to have this feature. And Bitpay including Bitcoin Cash will be the most important step for BCH in the next month's I guess.
Also, nothing I would have voted for people to work on but also nothing bad.

 

[adamstgbit]

I'm really excited what accident will pop the bubble this time.. Does Bitfinex has enough volume to pop the bubble when they go bankrupt or get hacked again?

theory is, their will be a big bang and the bubble will pop.

 

[Zangelbert Bingledack]

@go1111111 Every part of the system has externalities, it's the feedback from these externalities that sets the price. I prefer a more holistic approach.

I would phrase it as "mining cost externalities are internalized by orphan risk." Orphan risk incorporates the desires of other miners. Or as I have said a few times, the Keynesian beauty contest (among blocks) solves the tragedy of the commons.

The externalities - as far as the mining network itself is concerned - are rolled into the orphan risk metric. If miners' profit calculations didn't have to take other miners' views into account, there could be externalities, but their profit calculations do have to take other miners' views into account.

If we take into account non-mining nodes, there are externalities unless we roll those into the bitcoin price by the reasoning that it should upset investors.

 

[adamstgbit]

the moves are unfuckingblieveable
[doublepost=1511986161,1511985408][/doublepost]prediction the bounce WILL go over 10K

 

[Richy_T]

Just playing around with some block statistics right now and it occurs to me to wonder whether a different or additions transaction format would be a good idea. At the moment, transactions refer to txids. Because of the long nature of the blockchain, this means a UTXO set must be maintained to quickly look up unspent transactions for verification. Yet, as far as I can tell, this is only really useful for when an unconfirmed transaction references another unconfirmed transaction.

Wouldn't it make far more sense to store transactions in the blockchain which reference previous transactions as simply block number and position in block? Then following transactions back becomes a trivial and inexpensive lookup and UTXO does not need to be maintained. You might still want to support txids for the unconfirmed chains but as soon as one goes in a block, the conversion occurs.

 

[adamstgbit]

@Richy_T
how are you able to think of anything other then BTC price right now?
and
that sounds good, i guess when an unconfirmed transaction references another unconfirmed transaction, it would fall back on TXID lookup.
but
has the BTC bubble popped?

 

[Richy_T]

Price is boring already. Just prepping some popcorn waiting for the tether explosion.

I think a fork change would be in order because ideally wallets would be in on this too. If you want to send a transaction, if the tx reference is already confirmed, you send the block and location. Ideally you want to avoid the node having to do weird, time-consuming lookups. In fact, I'd be inclined to disallow chains of unconfirmed transactions anyway. Though I'm sure there's some reason they need to be there. In my book, people shouldn't be kiting checks.

If you think of the blockchain like a linked list, ideally, you want pointers to the parent to be a direct reference to the parent. In C, this would be a memory pointer. Could you imagine if you had to match the hash of memory contents in order to do linked lists? You'd be laughed out of the building.
[doublepost=1511989072][/doublepost]Here's a though: Are transaction accelerators causing (even more) problems for fee estimator routines? It's already hard enough to guess but when low fee transactions are getting in not based on financial incentives, you don't even have real data to work from.

Also, bear in mind transaction accelerators when someone tells you that transactions with low fees have been getting confirmed.

 

[adamstgbit]

I think a fork change would be in order because ideally wallets would be in on this too. If you want to send a transaction, if the tx reference is already confirmed, you send the block and location.

right, that makes scene, well good thing there is now a planned protocol upgrade every 6months
I edited my comment cuz I started to think it would infact require a fork.

If you think of the blockchain like a linked list, ideally, you want pointers to the parent to be a direct reference to the parent. In C, this would be a memory pointer. Could you imagine if you had to match the hash of memory contents in order to do linked lists? You'd be laughed out of the building.

lol.

Also, bear in mind transaction accelerators when someone tells you that transactions with low fees have been getting confirmed.

i didn't think of that, for sure thats the reason why it APPEARS that low fee TX are going threw sometimes.
[doublepost=1511990078][/doublepost]

Price is boring already. Just prepping some popcorn waiting for the tether explosion.

i'm not board! and i sure as hell not waiting for tether to explode, i'm busy selling... i was up till 2am last night, buying BCH, selling BTC for fiat, and now this crash, so exciting.

 

[Richy_T]

I sure hope that those who printed the monopoly money - if that is the case as the evidence suggests - ensure it is backed up, real quick. If that happens, it would be a pleasant surprise.

Word is, they're claiming it *is* backed. But by crypto, not USD. What could possibly go wrong?

 

[molecular]

There isn't even a repo I can find for Bitcoin Gold's version of Electrum.

The website for "Electron Gold" is just a shameless copy/paste of Electron Cash, complete with still saying that the binaries are signed by Jonald Fyookball, and they link to the Electron Cash repo!

One should add: those electron-gold binaries also have key stealers. (see (misplaced) discussion here: https://github.com/fyookball/electrum/issues/280)

 

[adamstgbit]

https://www.bitcoinunlimited.info/cash-development-plan

did we vote on any of this?
feels like this went over the BU members heads...

Support the technical community’s goal of planned protocol upgrades every six months – on the 15ths of May and November.

who can say no to that gem.

Increase the network capacity, ideally by decreasing the inter-block time to 1 min, 2 min, or 2.5 min to improve the user experience, focusing on faster and smaller blocks. To clarify, BU nodes and miners already have the ability to configure the block size limit as they see fit, even up to the original 32MB.

I feel like this is PROBABLY just fine. i guess "improve the user experience" sold me on this one.

Re-enable op-codes. Provide implementations for the proposed new OP_GROUP and OP_DATASIGVERIFY op codes and begin the process of restoring op-codes that were disabled soon after launch in 2009. These will permit representative tokens, binary contracts, and other advanced features.

seems a little ambitious, but definitely something to good to work toward.

implement a new Bitcoin Cash address format, to make it difficult for BTC to accidentally be sent to BCH wallets, and vice versa.

IMO i would say this is top priority

Evaluate the use of Bobtail to reduce inter-block time variance, increase double-spend resistance, improve the DDA, and achieve better mining. Overall, this change would further improve the user experience.

sounds fun.

Improve block relay, potentially by integrating Graphene. At the same time, evaluate the pros and cons of removing the causality requirement for transaction ordering within a block, to simplify Graphene's implementation.

if this is ready within 6 months that would be fantastic.

 

[Christoph Bergmann]

Word is, they're claiming it *is* backed. But by crypto, not USD. What could possibly go wrong?

I think it's possible that the tether are backed with crypto. When price goes up, good, if not, they might back it with shorts ... It's dazzling to imagine tether building up solid dollars out of nothing but crypto
[doublepost=1512009832][/doublepost]They would somehow trade against our for the dollar. It's risky, but after last months they have a good war chest

 

[solex]

https://www.bitcoinunlimited.info/cash-development-plan
did we vote on any of this?
feels like this went over the BU members heads...

Don't worry, the officers and developers of BU have to be pro-active in discussions with other groups, and give indications to them that we agree certain changes. We also need flexibility to promote changes in the community. As you have listed, none were against BU's vision and principles.

However, we will always have BUIPs to approve new functional changes, and/or protocol changes which affect the BU implementations (both for BCH and BTC). So, the members have the last say, and can effectively veto a change, or to be more exact: BU's participation in a change. We just proved that recently by the members killing support for SegWit2x, even though, to be honest, the officers of BU did favor participation in the NYA. The membership decision is final. As it happened, Jeff pulled the plug on 2x, but BU's decision was made before then.

The other thing to note is that we also have to be pragmatic, and the guiding principle is that BU development can follow the majority implementation by default (i.e. Core for BTC, and ABC for BCH), particularly as the software follows most chain-work. This is unless the members override one of their changes, for example, the members rejected Core's RBF.

For the recent Bitcoin Cash DAA change, there was not time for an override vote before the HF date, but the members can still decide to fork to their own DAA if they want. The power is there, and the test of the organization is that such power is used wisely.

 

[adamstgbit]

Don't worry, the officers and developers of BU have to be pro-active in discussions with other groups, and give indications to them that we agree certain changes. We also need flexibility to promote changes in the community. As you have listed, none were against BU's vision and principles.

right its understandable. its not like members can be expected to vote on what BU dev will talk about in meetings.

However, we will always have BUIPs to approve new functional changes, and/or protocol changes which affect the BU implementations (both for BCH and BTC). So, the members have the last say, and can effectively veto a change, or to be more exact: BU's participation in a change.

that's nice to know, and of course ( maybe i dont speak for everyone when i say this ), we members rely on the opinion of the devs when voting.

We just proved that recently by the members killing support for SegWit2x, even though, to be honest, the officers of BU did favor participation in the NYA. The membership decision is final. As it happened, Jeff pulled the plug on 2x, but BU's decision was made before then.

I think that a vote against segwit2x, was a vote for keeping the dev team focused on BCH. i think BU will have a hard time passing any BUIP that dosnt have to do with BCH, BU devs might not like it, but i think its probable BU will stop supporting BTC.

The other thing to note is that we also have to be pragmatic, and the guiding principle is that BU development can follow the majority implementation by default (i.e. Core for BTC, and ABC for BCH), particularly as the software follows most chain-work. This is unless the members override one of their changes, for example, the members rejected Core's RBF.

that's the thing, altho we get to vote on what BU does, we have to keep in-mind that BU must stay in consensus with the network it operates in. it would be silly for BU to veto a HF that has miner consensus.
But this is why BU must get miners running the BU software. hopefully in-time BU will gather significant hashing power behind it.

For the recent Bitcoin Cash DAA change, there was not time for an override vote before the HF date, but the members can still decide to fork to their own DAA if they want. The power is there, and the test of the organization is that such power is used wisely.

its a little scary to think BU member have the power to vote for a BUIP that throws BU out of consensus . but its hard to imagine why BU member's would place a vote that is clearly not in the best interest of BU...

 

[go1111111]

What's up with changing the time between blocks? This seems like breaking of the 10 minute canon. Am I missing something? Can anyone point me to where this was discussed?

Can you elaborate on what you're referring to? Does the current BCH code have properties that make the expected average block time not 10 minutes?

I vaguely recall Tom Zander saying that the new difficulty adjustment algorithm would result in block times slightly different from 10 minutes, which seems pretty bad, but I'm not sure where to find discussion of this.

 

[torusJKL]

its a little scary to think BU member have the power to vote for a BUIP that throws BU out of consensus . but its hard to imagine why BU member's would place a vote that is clearly not in the best interest of BU...

The scary part is that in this particular case a BU member could have written a blocking-BUIP in which case BU would not have been allowed to officially release a version with the new DAA until the next voting date.