Gold collapsing. Bitcoin UP.

[tynwald]

I like this q

@rocks
True, but now that situation has escalated, there may appear some fracture in their ranks.
Jonas Schnelli at least appears to me as relatively reasonable in his interview.

I like this quote from the interview "... I have no problem to jump over my own shadow. What I want is to make Bitcoin better" - about sticking with Bitcoin development if Classic fork goes ahead.

Nice attitude.

 

[sickpig]

@YarkoL any pointers to an actual PR/commit for such code changes? thanks in advance

 

[Justus Ranvier]

what about for example voting pools such as OT, and the robust stuff that could be built on top of that, like blinded Chaumian cash-type signatures?

FWIW, I don't think OT transactions with or without voting pools should be used as replacements for on-chain payments.

The goal of the voting pool design is to reduce the frequency of Goxxings, and that's difficult enough to achieve even if you assume a steady outflow of funds from the pool to help keep it honest.

What they should be used for, IMHO, is for transacting in things that aren't Bitcoin, while most Bitcoin transactions happen on the blockchain where they belong.

 

[cypherdoc]

Is it maybe worth rewinding on alot of the conventional wisdom that's completely taken hold of the mainstream just over the last six months?

For example, why is Lightning Network the default official reference client-endorsed winner for layer-2 functionality? I'm by no means any kind of expert on the subject, but what about for example voting pools such as OT, and the robust stuff that could be built on top of that, like blinded Chaumian cash-type signatures?

b/c LN is a Blockstream product?

i've argued for years how products like Factom, Counterparty, colored coins, Mastercoin, or anything that depends on OP_RETURN gets disadvantaged by higher tx fees and preferential treatment of LN.

 

[YarkoL]

@YarkoL any pointers to an actual PR/commit for such code changes? thanks in advance

Don't know about commits, but here they are in source

CBanEntry class

Ban methods

There are also data structures for containing banned nodes.

 

[Peter R]

I'm worried that Classic might stall because it requires miners to get on board to activate the block size limit increase...but miners are hesitant to get on board if they worry that nodes might not support them.

Unlimited is the best tool for the nodes to use to give permission to the miners to produce larger blocks. The worry about synchronization from the perspective of the non-mining nodes just adds friction to making the change. The nodes can increase their limits first (and asynchronously)!

If you want bigger blocks, you should run Bitcoin Unlimited and be willing to accept them TODAY. This even applies to the big companies like BitPay and Coinbase. In fact it is arguably the conservative decision as such nodes would follow consensus regardless of the resolution to the block size limit debate.

*****

What if we made a website called "Tear Down the Wall" (or more provocatively, "unblockthestream.com") where we tracked the user agent strings and updated a real time chart like this:

I think this would make users feel more empowered because they could see that their individual efforts help to break down the dam at 1 MB.

 

[cliff]

@Peter R - I think a very critical question with ideas like yours (which I like - I've been harping on signaling a binding commitment w/ my escrow post for the last few days (not commenting on quality of that post, btw)) is figuring out to how to signal that the commitment to the fork proposal is solid and will not disappear during the lead up to fork-thirty. In other words, how can the miners trust that the signals existing today will still be there tomorrow? I think there needs to be an incentive for running a big-block-node (BBN) and a disincentive or cost associated with backing out after starting (ideally, the disincentive/cost would provide a way to offset some of the losses miners would incur in planning to upgrade only to find out that the nodes reverted away from BBN). TL;DR - smart contracts may be part of the answer.

 

[albin]

What exactly is the attack where old nodes not upgraded to the hardfork get funds defrauded? I don't understand what the agitators in #debate on slack are trying to say.

Is it that the fork happens, and somehow the folks running the old node get confirmations on the side of the chain dying a thermodynamic heat death, but somehow those tx's never make it to the real post-fork main chain?

 

[rocks]

Is it maybe worth rewinding on alot of the conventional wisdom that's completely taken hold of the mainstream just over the last six months?

For example, why is Lightning Network the default official reference client-endorsed winner for layer-2 functionality? I'm by no means any kind of expert on the subject, but what about for example voting pools such as OT, and the robust stuff that could be built on top of that, like blinded Chaumian cash-type signatures?

I still have yet to see a realistic usage model for LN. The problem LN has it is trying to change end-user and merchant behavior away from payment models that are standard and easy for people to understand.

For example here is Rusty's own LN explanation on micro payments. Essentially once a payment is opened you can keep increasing a payment in incremental steps.
http://rusty.ozlabs.org/?p=450

A use case they have stated this solves is payment of on demand services. For example Netflix streaming could charge for every minute of streaming and expect payment as a video downloads, if you stop payment then the video stops.

The problem is this type of payment model is completely unnecessary. Almost every service I've ever seen offered falls into one of two types, one is a flat rate charge where a user receives the same monthly bill, and the other is a per use charge which accrues throughout the month and a single bill is sent at the end of the month.

In both cases only a single payment is needed per month. This is the way many services operate and it is good enough because there is enough trust both ways. Yes a customer may not pay at the end, but most companies are willing to eat that to keep things simple.

The problem is LN has confused payment with usage, and assumed the two need to be cryptographically tied to each other. This is wrong. Payment can be and almost always is separated from usage.

Cool tech, but I don't see it addressing any user needs in the payments space.

 

[Justus Ranvier]

In both cases only a single payment is needed per month. This is the way many services operate and it is good enough because there is enough trust both ways. Yes a customer may not pay at the end, but most companies are willing to eat that to keep things simple.

That business model works as long as their customer pool has a certain minimum credit-worthiness.

A prepaid model allows non credit-worthy customers to still get service, but prepayment has a downside of unused customer balances that are difficult to access if they aren't used.

The original (pre-LN) "rapidly-adjusted micropayment" concept is a great way to bridge the gap.

I think it's reasonable for businesses to start preferring real time billing when they can get it, because that means they can operate off cash flow rather than credit, which means they don't have to pay a vig to the commercial banks.

Additionally, businesses which are not reliant on credit are not beholden to banks to roll over their loans, so they aren't vulnerable to being instantly bankrupted during a credit crunch.

Of course, for that model to work, their customers need to have positive net worth and cash flow and not be reliant on credit themselves...

If we see a Bitcoin-precipitated transition to a savings economy instead of a credit economy, we're going to see deep changes in how commerce works. Much of what we take for granted as almost immutable laws of nature is going to be revealed to be a credit bubble-induced aberration.

 

[Erdogan]

BTC at new all-time high in barrels of oil.

Or inverted: Oil is all time low in bbl/BTC.

I like that people make these indexes of stuff priced in btc. And why not? BTC is a world money, and there is no concealed value depression, there is no man behind the curtain. In a couple of years bitcoin can be good as a unit of account for price comparisons over the long run.

 

[albin]

@Justus Ranvier

I think that's a fantastic point, a lot of b2b credit arrangements exist simply because there is no way to cash settle like Bitcoin allows. I've seen a lot of situations in supply chain / logistics for example where this tremendous administrative friction leaves potential revenues from high-turnover and emergency one-off business on the table.

 

[rocks]

That business model works as long as their customer pool has a certain minimum credit-worthiness.

A prepaid model allows non credit-worthy customers to still get service, but prepayment has a downside of unused customer balances that are difficult to access if they aren't used.

The original (pre-LN) "rapidly-adjusted micropayment" concept is a great way to bridge the gap.

I think it's reasonable for businesses to start preferring real time billing when they can get it, because that means they can operate off cash flow rather than credit, which means they don't have to pay a vig to the commercial banks.

Additionally, businesses which are not reliant on credit are not beholden to banks to roll over their loans, so they aren't vulnerable to being instantly bankrupted during a credit crunch.

Of course, for that model to work, their customers need to have positive net worth and cash flow and not be reliant on credit themselves...

If we see a Bitcoin-precipitated transition to a savings economy instead of a credit economy, we're going to see deep changes in how commerce works. Much of what we take for granted as almost immutable laws of nature is going to be revealed to be a credit bubble-induced aberration.

Yes, as you said the prepaid model allows non credit-worthy customers to get services, but how is LN better or easier here?

LN payments look very similar compared to the prepaid model. In both cases the user has to send and lock funds away for a period of time. The prepaid balance is then reduced as the service is consumed, and finally any remaining balance is returned (or expires).

Compared to the prepaid model, LN offers no benefits for the merchant. With prepaid services the merchant has no risk because they've already received payment. It is not clear to me now LN is better for the merchant. I guess you can say LN is better for the user because they can close the channel and received unused funds back, but the user here doesn't determine the system used, the merchant does and if I was a merchant I'd prefer the current system over LN.

And that is just the prepaid market which probably is not a majority of Bitcoin users. A majority of Bitcoin users probably use monthly billing.

Basically I still have yet to see a valid LN use case that is good enough to change merchant or user behavior, which is a big hurdle. Instead what I've seen is every Bitcoin service that has appeared and is popular, functions very similar to existing payment methods.

@albin
There could definitely be new use cases in that space.

The problem still is the positioning LN as a scaling solution for Bitcoin. It simply is not because it does not improve most of the existing use cases people are using Bitcoin for. Creating new use cases is great, but that is not a scaling solution but a new offering.

 

[cypherdoc]

I still have yet to see a realistic usage model for LN. The problem LN has it is trying to change end-user and merchant behavior away from payment models that are standard and easy for people to understand.

For example here is Rusty's own LN explanation on micro payments. Essentially once a payment is opened you can keep increasing a payment in incremental steps.
http://rusty.ozlabs.org/?p=450

A use case they have stated this solves is payment of on demand services. For example Netflix streaming could charge for every minute of streaming and expect payment as a video downloads, if you stop payment then the video stops.

The problem is this type of payment model is completely unnecessary. Almost every service I've ever seen offered falls into one of two types, one is a flat rate charge where a user receives the same monthly bill, and the other is a per use charge which accrues throughout the month and a single bill is sent at the end of the month.

In both cases only a single payment is needed per month. This is the way many services operate and it is good enough because there is enough trust both ways. Yes a customer may not pay at the end, but most companies are willing to eat that to keep things simple.

The problem is LN has confused payment with usage, and assumed the two need to be cryptographically tied to each other. This is wrong. Payment can be and almost always is separated from usage.

Cool tech, but I don't see it addressing any user needs in the payments space.

Great point. This is the problem with geeks and the real world; over engineering things. It'd be like charging someone in a restaurant, while they're eating. It's just not necessary. But in a cipherpunk world where you don't trust anyone, it seems necessary. Perhaps I shouldn't insult the cipherpunks and place blame where it belongs; core dev.

 

[Justus Ranvier]

Compared to the prepaid model, LN offers no benefits for the merchant. With prepaid services the merchant has no risk because they've already received payment. It is not clear to me now LN is better for the merchant. I guess you can say LN is better for the user because they can close the channel and received unused funds back, but the user here doesn't determine the system used, the merchant does and if I was a merchant I'd prefer the current system over LN.

All other things being equal, the merchant who offers most customer-friendly payment methods should do better than the merchant who doesn't.

(I'm not sure it's accurate to call this the "LN model", since it pre-dates LN.)

A safe prepayment model can convince customers who are accustomed to post-payment to switch to pre-payment, which does benefit the merchant's cash flow.

 

[lunar]

@Justus Ranvier

• The dominant implementation must have close to 100% market share

• The dominant implementation must have close to 0% market share.

A few weeks back I was wondering as to how this would actually play out? if we had 100 implementations each with a 1% node/market share. Not getting forked off the network becomes paramount, and improvement ideas will be judged solely on their own merit rather than what client/dev produced them.

Surely we are going to need/forced to have, some sort of ossified base level of the protocol, otherwise it's going to be virtually impossible to figure how each client interacts?

(eg) It could be true; certainly there are no guarantees that all the miners and the majority of nodes aren't already running slightly personalised code that currently accepts 2MB blocks. If this was the case, just one block produced at 1.01MB and a completely unexpected hard fork would occur?

....................
more on the china digital currency story 'zerohedge' spin
http://www.zerohedge.com/news/2016-01-20/war-cash-escalates-china-readies-digital-currency-imf-says-extremely-beneficial

 

[Peter R]

@Peter R - I think a very critical question with ideas like yours (which I like - I've been harping on signaling a binding commitment w/ my escrow post for the last few days (not commenting on quality of that post, btw)) is figuring out to how to signal that the commitment to the fork proposal is solid and will not disappear during the lead up to fork-thirty. In other words, how can the miners trust that the signals existing today will still be there tomorrow? I think there needs to be an incentive for running a big-block-node (BBN) and a disincentive or cost associated with backing out after starting (ideally, the disincentive/cost would provide a way to offset some of the losses miners would incur in planning to upgrade only to find out that the nodes reverted away from BBN). TL;DR - smart contracts may be part of the answer.

I wonder if we could create a big-block insurance fund and sell "orphaning insurance" to miners. The cost of the insurance per block would depend on the size of the block (and possibly other variables). We would promise to pay out (for example) 25 BTC for insured blocks that got orphaned. Right now, the premiums for a block over 1 MB in size would be extremely expensive, but eventually--if we see enough mining and non-mining nodes increase their *acceptance* limits--there might come a time when we'd only charge (say) 0.1 BTC for insurance on a 2 MB block.

Miners would probably need some automated way to get real-time quotes and buy instant coverage; perhaps someone could actually make money off this if he understood the orphaning dynamics better than anyone else.

 

[rocks]

I think that's a fantastic point, a lot of b2b credit arrangements exist simply because there is no way to cash settle like Bitcoin allows. I've seen a lot of situations in supply chain / logistics for example where this tremendous administrative friction leaves potential revenues from high-turnover and emergency one-off business on the table.

That is a good point, but for many segments the credit model is needed to manage working capital needs in the value chain. Moving the credit model to a prepayment or pay on delivery model would break many segments I've seen.

Take for example the TV distribution industry. Very simplified it works as follows:

TV manufacture sells and delivers TV on credit to a distributor
Distributor sells and delivers TV on credit to a retailer
Retailer sells to end customer and receives payment

The typical revolving credit terms here are 90 days, which magically work out to be a bit more than the average stock in the system and flow rate from TV manufacturer to end customer.

The value chain of this business segment requires credit to function. Neither the distributor nor the retailer have enough working capital to pre-pay for their stock. The credit risk is a pain for the manufacturer to manage, but it is necessary to make the value chain function. (The credit btw is considered relatively safe because it is backed by the physical good.)

The TV manufacture would prefer to receive cash, but if it did so the retailer could not operate on the slim margins they do. For the TV manufacture to move to cash payment, retailer margins would have to significantly increase, which increases the cost of their product and lowers sales. Credit is a pain, but overall a benefit to the manufacturer.

A lot of B2B segments I believe look similar. Credit exists because only at the end of the value chain does money enter the system and flow back up. Prepayment models break this and cause working capital to increase throughout the value chain, which makes the value chain less lean, less efficient and more expensive to operate.

 

[Justus Ranvier]

Neither the distributor nor the retailer have enough working capital to pre-pay for their stock.

Sure, if you just take that fact as a given and never examine why it came to be true in the first place, then all the rest of the arrangement makes sense.

But how did those distributors and the retailer get into that predicament in the first place?

Credit is cheap (but not free!) for two reasons:

• The money funding the loans was printed (borrowed) into existence.
  
• Savers are desperate to escape the devaluation caused by the prior point, so they make their savings available to fund loans in situations in which they otherwise wouldn't

Once a business starts using credit to fund its operations, the interest becomes a barrier to earning their way into a state of not requiring more loans.

If the temptation of easy credit isn't enough, then the government is more than happy to use tax policy to forcefully shove them into a credit addition.

Basically 95% of the financial/banking industry is an expensive solution to artificial problems created by that industry and their government accomplices.

The concept of cash savings as "wasted idle capital" only exists in an economy chronically punished by inflation. The idea of money that belongs only to its owners such that uninvolved third parties can't collect rent on is it going to horrify a tiny minority of financial parasites, but they'll just have to learn to accept it and get real jobs.

 

[cliff]

I still have yet to see a realistic usage model for LN. The problem LN has it is trying to change end-user and merchant behavior away from payment models that are standard and easy for people to understand.
.

Not saying its a good model, but https://en.wikipedia.org/wiki/Hawala