Gold collapsing. Bitcoin UP.

[rocks]

Thanks for the clarifications

Thinblocks alone has the potential to allow real-time block propagation to be as efficient at 32MB as standard blocks are at 1MB.

Personally, I think Xthin + your mini-blockchain idea (what I called subchains) will allow us to scale on chain by at least two orders of magnitude. This combination is my preferred solution since Xthin and subchains are both dead simple. Furthermore, this solution does not require mempool homogeneity but naturally incentivizes it instead (nodes with highly-synchronized mempools will receive and transmit blocks faster but the solution works regardless).

Agree this is the easiest path for scaling. If we use @solex's 32MB number and assume sub-chains are issued every 10 seconds (60 sub-chains per block on average), that means that we can get to 32MB * 60 = 1.92GB blocks with the same orphan rates as today. That is huge and means we can easily handle a large amount of traffic.

Given the significant fees a 2GB block would contain, it is reasonable miners would be willing to risk slightly higher orphan rates to increase block sizes further. Miners could mine 10GB/blocks with modestly higher orphan rates than today but capture a lot of fees.

These two techniques should be able to meet scaling needs for at least the next decade (or two) even if Bitcoin continues exponential growth, and it sounds that thin blocks is enough for the next few years at least which gives time to implement sub-chains.

 

[cypherdoc]

great work, all you guys @theZerg @Peter Tschipper @YarkoL @solex @Peter R

ultimately, BU is the soln we should be striving for. in the meantime, lotsa headaches. w/o you guys, it would be a lost cause.

 

[cypherdoc]

i'd like to start a discussion on the inter-relationship of onchain tx fees as they relate to LN tx fees, assuming both the concepts of Bitcoin as a "settlement layer" and the inevitability of LN "hubs", given that decentralized routing seems to be an as yet unsolved problem. i think the latter is a reasonable assumption also given that the SC model of an spv proof seems to be on the back table (the current effort appears to try and insert CT directly into the protocol via the wide open script versioning introduced by SWSF). the other evidence is what we have now instead is the centralized federated server model exemplified by Liquid for several clubby exchanges.

what doesn't make sense to me is what the 1MB'ers claim; high fees onchain with low fees offchain. i would think there would be an equilibrium of either low-low, high-high, or medium-medium fee levels. the question is whether this equilibrium would be btwn the open/close payment channel tx's and normal onchain settlement tx's or the intermediate path channel tx's and normal onchain settlement tx's. what i'm getting at is that if onchain settlement tx fees are expensive then why wouldn't LN tx fees be equally as expensive, if you believe an equilibrium will exist?
[doublepost=1455766432,1455765341][/doublepost]

 

[_mr_e]

Xthin blocks "work" if the receiving node does NOT have all the transactions in its mempool too [1]. When the receiving node makes its get-block request, it attaches a bloom filter that describes the contents of its mempool. The transmitting node then sends the Xthin block + any missing transactions in full as inferred from the bloom filter. This is fast and efficient.

Personally, I think Xthin + your mini-blockchain idea (what I called subchains) will allow us to scale on chain by at least two orders of magnitude. This combination is my preferred solution since Xthin and subchains are both dead simple. Furthermore, this solution does not require mempool homogeneity but naturally incentivizes it instead (nodes with highly-synchronized mempools will receive and transmit blocks faster but the solution works regardless).

[1] Except for false positives which should occur approximately 0.1% of the time.

Wouldn't validation still be a huge bottleneck on blocks that large?

 

[Peter R]

@_mr_e:

By validation, do you mean the time required to check for each transaction that its spent outputs exist in the UTXO and that the signatures are valid?

If I'm interpreting this post by Rusty Russell correctly, it looks like he's estimating that with libsecp256k1 and a decent hardware setup, it should take about 1.1s to validate an 8MB block assuming the block has been fully received (and much less time if most of the transactions in the block have already been verified).

Assuming the validation time scales linearly, the same setup could validate 4.4 GB of transactional data in 10 minutes. This tells me that we probably won't have to worry too much about validation until blocks are measured in hundreds of megabytes (and by that time, we'll have hardware ECDSA accelerators built into the latest Intel processors ).

 

[go1111111]

what i'm getting at is that if onchain settlement tx fees are expensive then why wouldn't LN tx fees be equally as expensive, if you believe an equilibrium will exist?

Imagine that on-chain txns are $5 each, because the block size is so small relative to demand. Imagine there is almost no cost to routing a Lightning transaction on an existing channel. So a channel will be created when the creator(s) think they can get $10 of value out of using the channel. If the hub expects to process 5000 transactions on that channel, then if it charges 0.2 cents per transaction it will break even. This assumes the hub will pay the open/close cost though -- most likely the user will pay those because the hub won't have much guarantee that the user will send at least 5000 transactions. A user will probably want to only open a channel with a large amount of money, like $1000 or more.

Basically, the fees involved will be determined by the marginal cost of each tx type. The marginal cost of a LN transaction doesn't depend on the open/close fee (the on-chain fee), so you should not expect them to be in equilibrium.

 

[Christoph Bergmann]

Open Transactions is not a replacement for on-chain transaction capacity.

I do think OT has a place in Bitcoin wallets, but that place is adding entirely new functionality, not doing Bitcoin's job for it.

Yes. Nothing can replace on-chain transactions, since this is the onliest conncections to bitcoin's functionality.

But I share the sentiment that we don't need to save everybody's coffee-transaction on 5.000 computers all over the world secured by the strongest global computer network. I know, I'm not the one to decide what is spam and not, I strongly oppose the idea that anybody can define what's spam or not, and I know that if we say "no coffee" today we have to ask why we don't say "no monitor" tomorrow.

But beside that there should be no doubt that it's better for the network if we don't save everybody's coffee-transaction onchain as long as it's possible to process them. So it's crucial to provide and develop channels where we can process everybody's coffee-transaction in realtime.

I read the whitepaper of stash (open transactions) and wrote emails with Chris Odom. For me this system seems to be very advanced, conceptually way more "ready-to-go" than lightning while I see no disadvantage with it. So I just wonder why nobody speaks about it.
[doublepost=1455791867,1455791113][/doublepost]Yesterday I tried to send a tx without fee.

26 hours later it's still not confirmed. I wonder if it ever gets through.

 

[sickpig]

idle thought:

if

1) cashless society
2) gov in charge of monetary supply
3) negative interest rate (IR)
4) IR > derivative(prices function)

then:

Your money lose purchasing power even if in a deflationary economic conjunction


am I right ?

 

[sgbett]

It just occurred to me:

Contention appears to be the remaining issue. Core has the power to fix that. Given they have stated 2MB isn't a problem.

I'd tweet it but I'm nobody

 

[lunar]

Classic nodes now up to ~1400 (21%) https://bitnodes.21.co/nodes/?q=/Classic:0.11.2/

not sure how valid all of these new nodes are? I guess at least we know there are sufficient to support the network should a fork to 2MB occur soon.

Time for some some of that supporting hashpower to act.

 

[yrral86]

@lunar
We don't even know that. Nodes can be faked with software that connects to bitcoin nodes and only implements enough messages to convince the node counter. It could pass though any other requests to a real node. Even blocks could be lying about what they will support if someone really wanted to fuck shit up.

 

[awemany]

Fun calculation:

Bitcoin's total number of hashes since genesis block: ~ 2^84
One mol of substance: 6.022e23 atoms or molecules
=> 32.12 mol of hashing

Molar mass of water: 18.015 g/mol, density ~ 1g/cm3:

=> 578 ml

Thus:

Would each hash done by the Bitcoin network be equivalent to enumerating one molecule of water, the Bitcoin network would by now have enumerated each single molecule in about 1 imperial pint of water.

 

[chriswilmer]

Slush pool's support told me in an email that they enabled Classic mining yesterday. I haven't heard anything about this on reddit/social-media. Can anybody confirm this with a miner?

 

[sickpig]

@chriswilmer

last slush mined block:

https://blockchain.info/block-index/000000000000000002f2b4862acc8a9800a08572dbf643e50b295aef8dd867a6?site=slush

block version = 4

if it were a classic block version should be equal to 805306368
[doublepost=1455808875,1455808076][/doublepost]

say hi to the third bitcoin classic block:

https://blockchain.info/block/000000000000000003c44b5606c8fe695a24c6c1b87bd438d86c7d418025e9f0

courtesy of AntPool

 

[Inca]

Imagine that on-chain txns are $5 each, because the block size is so small relative to demand. Imagine there is almost no cost to routing a Lightning transaction on an existing channel. So a channel will be created when the creator(s) think they can get $10 of value out of using the channel. If the hub expects to process 5000 transactions on that channel, then if it charges 0.2 cents per transaction it will break even. This assumes the hub will pay the open/close cost though -- most likely the user will pay those because the hub won't have much guarantee that the user will send at least 5000 transactions. A user will probably want to only open a channel with a large amount of money, like $1000 or more.

Basically, the fees involved will be determined by the marginal cost of each tx type. The marginal cost of a LN transaction doesn't depend on the open/close fee (the on-chain fee), so you should not expect them to be in equilibrium.

On chain fees will never rise to 5 dollars. It simply won't happen. It is possible to hypothesise a working system now and one with LN with on chain fees and millions of users at 5 - 20$. But actually describing how we go from 0.05 - 0.10 $ to 5$ without value leaving the ecosystem for crypto which scales is another matter.

edit: @awemany or beer! i'd drink to that!

 

[freetrader]

Classic nodes now up to ~1400 (21%) https://bitnodes.21.co/nodes/?q=/Classic:0.11.2/

not sure how valid all of these new nodes are?

 

[Richy_T]

extreme thin blocks is really working!!

2016-02-17 21:00:14 Reassembled thin block for 00000000000000000103fbd5825a1ef895303c9791115a25974acebdeb797cb1 (949180 bytes). Message was 16580 bytes, compression ratio 57.248493

(that's the highest compression of a near 1MB block I got in a few hours)

Couple of monster txns in this one:

2016-02-17 21:41:03 Reassembled thin block for 00000000000000000236b1c505e8bc8b8b8991a9d01d5f5a51c01f8504a87f5f (291671 bytes). Message was 3093 bytes, compression ratio 94.300354

Please consider posting this on /r/btc. Seems newsworthy.
[doublepost=1455811891][/doublepost]

If you were in charge of 21.co what would you do? So I assume they are just hedging their bets? If blockstreamCore are successful in their attempt to siphon fees from the miners to their proprietary payment channels at the expense of future mining profits and hence network security, i'd think 21 would want in on that action too.

I believe it's possible to want to get in on the alternative channels option without believing you have to cripple Bitcoin to do so. (Though I have no idea of 21.co's intentions). Bitcoin transactions will always have a non-zero cost and not be suitable for small micro-transactions *naturally*. There's opportunity for profit there.

 

[Inca]

0.12 released.

Now shit gets real.

 

[albin]

On chain fees will never rise to 5 dollars. It simply won't happen. It is possible to hypothesise a working system now and one with LN with on chain fees and millions of users at 5 - 20$. But actually describing how we go from 0.05 - 0.10 $ to 5$ without value leaving the ecosystem for crypto which scales is another matter.

I think that you're totally right about this, there's no conceivable smooth path from the status quo to Peter Todd's mythical "$20 wire transfers". This speaks to the fundamental bootstrapping problem inherent to the settlement pivot, you can't settle using a currency nobody can use. The backlash against Bitcoin would be so tremendous, and frankly justified. We'd be the laughing stock of every ignorant person with a passing interest in tech or finance ("hahahaha where's those cheap transactions").

 

[Richy_T]

Imagine that on-chain txns are $5 each, because the block size is so small relative to demand. Imagine there is almost no cost to routing a Lightning transaction on an existing channel. So a channel will be created when the creator(s) think they can get $10 of value out of using the channel. If the hub expects to process 5000 transactions on that channel, then if it charges 0.2 cents per transaction it will break even. This assumes the hub will pay the open/close cost though -- most likely the user will pay those because the hub won't have much guarantee that the user will send at least 5000 transactions. A user will probably want to only open a channel with a large amount of money, like $1000 or more.

Basically, the fees involved will be determined by the marginal cost of each tx type. The marginal cost of a LN transaction doesn't depend on the open/close fee (the on-chain fee), so you should not expect them to be in equilibrium.

If Blockchain fees are really so high, no doubt we will see LN channels find a way to interact with each other, making the blockchain effectively obsolete. I can't see a way this ends well if Bitcoin is obstructed from being competitive.