Gold collapsing. Bitcoin UP.

[cypherdoc]

a reminder why gvt digital currencies are likely to fail. Mintchip:

https://medium.com/@beautyon_/why-mint-chip-died-673faa065a82

 

[Justus Ranvier]

The Fedcoin briar patch...

How awful it would be to have a highly liquid, low friction gateway between Bitcoin and the USD.

Bitcoin would have to compete on monetary policy alone.

 

[Peter R]

Andolfatto is awesome: he's willing to put FedCoin toe-to-toe against Bitcoin. If central banking really works, shouldn't people prefer to transact in FedCoin? I suspect the fight will come sooner than later.

 

[Melbustus]

Help me out, guys....let's also get some good discussion going on /r/btc to pull activity from /r/bitcoin: https://www.reddit.com/r/btc/comments/3sl4i2/david_andolfatto_vp_st_louis_fed_bitcoin_and/

 

[cypherdoc]

here's a good one i hadn't thought of:

 

[Peter R]

Theymos responds to me here:


And then claims the XT crew has shown their "true intentions" on the XT #REKT thread (which I assume he means to "inflate" bitcoin, even though if he had included the rest of my quote it would be obvious that I wasn't suggesting that):

I think it has been a productive day in Bitcoin social media. Lots of good action.

 

[cypherdoc]

@Peter R
that is precisely why i try never to be sarcastic or joke around malicious miniblockers.

they'll distort and run with it.

 

[Peter R]

I wasn't joking about anything.

I think Theymos response re-iterates how he thinks there are two different "consensuses": one formed by the longest persistent chain and another more abstract one that is based on his view of what Bitcoin is. In other words, he thinks the answer to /u/ForkiusMaximus's quiz would be (a) and (b) but not (c).

 

[cypherdoc]

gaud, this is so beautiful. Visa:

https://www.cryptocoinsnews.com/visa-europe-collab-partners-epiphyte-using-block-chain-improve-global-remittance/

Bitcoin will not be denied. even if they have to blockchain first.
[doublepost=1447370045,1447369137][/doublepost]this is a great article. but this was the best part; reading just how far off the mark some of these guys are when it comes to understanding Bitcoin's security model. and this guy is from Kaspersky:

"Vitaly Kamluk, principal security researcher at Kaspersky Lab, which advises clients on digital security, argues that the decentralised nature of distributed ledger technology has still to be reconciled with how such databases can be maintained cleanly and securely.

The problem with malicious actors can be quite easily solved when it’s a centralised technology,” he says. “[But] this is yet to be solved in cases of decentralised architectures where each participant has equal rights and cannot enforce a sole decision.”

http://www.ft.com/cms/s/2/eb1f8256-7b4b-11e5-a1fe-567b37f80b64.html

keep buying the dips!

 

[AdrianX]

If central banking really works, shouldn't people prefer to transact in FedCoin? I suspect the fight will come sooner than later.

Worst case it'll be a pegged* side-chain, and when it starts to fail it could be propped up with a 1934 style Gold Reserve Act and suck the life out of bitcoin.

*pegged meaning anything but 1:1 long term.

 

[Justus Ranvier]

this is yet to be solved in cases of decentralised architectures where each participant has equal rights and cannot enforce a sole decision.”

This reminds me of related conversation I had regarding smart contracts: "How will smart contracts be enforced?"

My reply was, "Assuming that contracts need to be enforced is begging the question. The purpose of contracts it to be useful for facilitating trade. If enforcement causes certain contracts to be better at achieving this goal, then great. However there's no reason to assume that enforcement is required for all contracts to be useful for facilitating trade."

This person is assuming that consensus must be enforced.

His blind spot in this area is so profound that he doesn't even realize that, "does consensus automatically imply enforcement?" is even a question.
[doublepost=1447370798][/doublepost]Imagine what it would be like to spend a lot of time searching for a solution for distributed enforcement of something only to learn later that you understood the problem poorly from the beginning and enforcement isn't even required at all (let alone possible).

 

[cypherdoc]

ok, Blythe Masters has revealed her hand. we're in for a fight:

 

[rocks]

One way or another, the process of transmitting blocks through the network is going to get temporally smoothed. Instead of a block being a monolithic thing that appears out of nowhere every 10 minutes, miners are going to continually broadcast compressed information about the contents of their upcoming block so that when they find a valid hash all they need to broadcast is a constant-size header.

... however, @awemany and I were working on a proof to show that it's actually impossible to achieve true O(1) block transmission ....

It is also impossible to ensure that mempools will be completely uniform across the network, so there is a risk that some transactions included in the block will not be in everyone's mempool. This risk could vary by transaction (for example very recent transactions might not have propagated to all nodes before that block is found).

I have been kicking around scaling ideas for a while and think there is a method that can achieve the following benefits:

1) Smooths block transmission evenly over the period between blocks
2) Achieves a true O(1) block transmission (that consists of just a header packet)
3) Improves the security of 0 confirm transactions
4) Economically incentivizes miners to include every fee paying transaction, and eliminates the current economic incentive to issue zero transaction blocks
5) Aligns mempools between nodes in a verifiable manner
6) Does not fork or change bitcoin in anyway

Here is the proposal I've been thinking on, feel free to tell me why this wouldn't work or why I'm crazy.

What if miners created mini-blocks between themselves, similar to how P2Pool functions, and used a chain of these mini-blocks to pre-transmit transactions to include in the next block. Here miners would agree to merge mine a lower difficultly mini-block chain that issues blocks at smaller intervals (let's say every 20 seconds on average). These mini-blocks would contain new transactions seen since the last block or mini-block. As mini-blocks are found, miners would build succeeding mini-blocks of new transactions on top of the previous mini-block, and through that process build a chain of mini-blocks that contain new transactions received since the last real main chain block. To speed transmission of mini-blocks, they would be transmitted using an IBLT of thin block headers to compress transmission the same as how real blocks can be compressed.

What this does is build a chain of mini-blocks that contain transactions to be included in the next real block. Now when a real block is found, the winning miner would only have to transmit the block header and the latest mini-block hash. Receiving nodes would reconstruct the block's transactions from the chain of mini-blocks that were built since the last block was found. If the receiving node did not have the very latest mini-block, it would only have to request the mini-blocks it hadn't received yet, which should just be 1 or 2 at the most out of the many found since the previous real block.

Such a method would provide the following properties:

1) No fork is required and there are no changes to bitcoin. The mini-block chain is just an informal method for nodes to communicate transactions to include in the next block between themselves. Any non-participating miner could still issue standard blocks not using the mini-block chain method
2) Transmission of agreed transactions to include would occur at regular intervals throughout the 10 minute average window, smoothing block propagation
3) Zero-confirm transactions could see if they are included in the next mini-block, and once they are be reasonably confident the next real block will contain the transaction. This would improve confidence in zero-confirm transactions, and be quoted as 0.1 confirmations or 0.2 or 0.3 etc. as the mini-chain builds.
4) The cost to transmit a real block is reduced to O(1). Since the winning miner is simply identifying the mini-block chain it decided to include (with it's hash), all that needs to be transmitted is the new real block header and the hash identifier of the mini-block chain to use.
5) Because of #4 above, the economic incentive to produce 0-transaction blocks is eliminated. The pre-sent mini-block chain contains fees available to claim, and the cost of claiming those transactions is zero compared to issuing a 0-transaction block.
6) Because of #5 above, miners are now economically incentivized to include as many transactions as possible.
7) The transmission of the next block is sent evenly over the period between blocks
8) All block compression techniques currently being discussed can also be used with mini-blocks.

If you assume 10 minute average real blocks, 20 second mini-blocks, a thin block header compression ratio of 14x and an IBLT compression ratio of 10x; then to support a transaction volume of 100MB every 10 minutes (i.e. 100MB blocks) nodes would only have to send 23KB every 20 seconds. By sending 23KB every 20 seconds, 100MB's of pre-broadcast transactions to include in the next block could be acknowledged by the network.

An advantage of using mini-blocks as a communication mechanism only, and not as a confirmation mechanism, is it removes many of the downsides of having smaller block time windows. Moving to less than 10 minute blocks increases orphan risk and requires users to need multiple block confirmations to be confident. Here the block time window is still 10 minutes, the mini-blocks are simply a method for miners to communicate the blocks they intend to include in the next block among each other. There is however no confirmation promise on them.

So are their reasons why this won't work? It seems as if it should to me but I'm not sure what I'm missing here.

 

[cypherdoc]

ok, Blythe Masters has revealed her hand. we're in for a fight:

note how Blythe blithely refers to negative interest rates as "a legtimate tool of monetary policy" as opposed to "financial oppression".

 

[AdrianX]

1) Smooths block transmission evenly over the period between blocks
2) Achieves a true O(1) block transmission (that consists of just a header packet)
3) Improves the security of 0 confirm transactions
4) Economically incentivizes miners to include every fee paying transaction, and eliminates the current economic incentive to issue zero transaction blocks
5) Aligns mempools between nodes in a verifiable manner
6) Does not fork or change bitcoin in anyway

something this big deserves to be posted in the morning before I've exhausted my brain power.

note to self come back in the morning.

 

[Zangelbert Bingledack]

BTCdrak, another relatively bearish dev, apparently, who doesn't seem to understand Bitcoin's monetary network effect as being in the ledger:

 

[Justus Ranvier]

2) Achieves a true O(1) block transmission (that consists of just a header packet)

There's a tiny semantic error in this statement that is nevertheless a source of a huge amount of non-productive argument.

There is no such thing as O(1) block transmission.

What you're talking about is constant-time transmission of block solutions.

Transmitting a block solution is only helpful if the recipient of your transmission already has the block it solves, either because you transmitted the block itself prior to the solution or (more likely) the information needed for the recipient to assemble the block himself.

The reason it's important to pay attention to the difference between blocks and block solutions is that when you talk about constant-time block propagation people forget about the cost associated with pre-broadcasting the block which allowed the miner to use constant-time block solution transmission in the first place.

 

[Mengerian]

From the Stephen Pair AMA:

Chris Wilmer: Now my question: What are you doing to help mold consensus around BIP101 (or if not that, some other block size solution)? Are you flying out to meet with miners? Are you calling up other people in the ecosystem? If you have been doing this, how have those conversations been going? What sort of counterarguments are you getting?

Stephen Pair: We've been talking to other companies, miners and core developers about it. I also went to the Scaling Bitcoin conference in Montreal (which I thought was one of the best Bitcoin conferences I'd ever attended). We had hoped that a consensus would be reached among core developers and we would follow that consensus, but it got to a point where we thought we needed to make our views known. The counter arguments are generally along the lines that if you increase the resource requirements on a node, less people will run nodes and bitcoin will become centralized. People also state that bitcoin can/should be used as a settlement layer. We of course agree that bitcoin must remain decentralized. While an increase in resource requirements for a node will discourage more nodes, an increase in throughput will accommodate more adoption, which will encourage more nodes. The economic decision to run a full node has to do with how much you value the ability to independently and trustlessly validate transactions. That ability is worth a lot if you assume Bitcoin enjoys widespread adoption. In addition, there is a lot of room for optimization that would reduce the resource utilization of a node. Regarding the settlement layer arguments, I don't think Bitcoin is compelling as a settlement layer unless it enjoys widespread adoption as a payment network. Bitcoin's utility as a payment system is its intrinsic value. If it's not useful for that purpose, it doesn't really have any value. If it doesn't have any value, it has no value as a settlement system. To put it in other words, if it cannot be practically used to pay people for things, then why would you have any interest in using it for settlement?

 

[Justus Ranvier]

BTCdrak, another relatively bearish dev, apparently, who doesn't seem to understand Bitcoin's monetary network effect as being in the ledger:

Of course he doesn't - he's the lead developer for a competing currency.

He wants to be the CEO of Burger King who competes with, but ultimately shares a market with, the CEO of McDonalds.

The idea that competing currencies are like competing measurement systems - a source of economic friction that the market works diligently to eliminate - is not something he's going to welcome.

 

[cypherdoc]

BTCdrak, another relatively bearish dev, apparently, who doesn't seem to understand Bitcoin's monetary network effect as being in the ledger:

that guy is simply a troll