Gold collapsing. Bitcoin UP.

[cypherdoc]

this

 

[Epilido]

If there is value in having a certain ordering then miners might uphold that ordering to strengthen the ecosystem. Zero conf is an example where miners voluntarily provide such a service.

Zero conf is unsafe if miners do not obey the first seen rule, or worse collaborate with scammers. Nothing in the consensus protocol forces zero conf to work. Let's cross our fingers that miners will understand for all time that upholding reliable zero conf is critical for the ecosystem.

Actually, I'd like to see miners make public statements that they guarantee certain zero conf behavior. Miners should form a business association to make sure that certain standards are reliably upheld.

Zero conf allows for a decreased level of security as a trade off for fast low value transactions.

The statement that there is value in the ordering of transactions in a block. There is no method to verify that they actually came in that order. So going back to a particular block sometime in future and stating that this transaction from a to b happened before the transaction c to d can't be verified to be accurate.

 

[Norway]

You would have no proof that the miners are ordering this way. What value does the data have if it clearly could be placed in any order. Someone could pay the miner to change the order for specific transactions. Invalidating any value of the data. Since the block is only time stamped at creation all the transactions have the same time stamp.

Any use of the data based on the ordering of transactions in a block requires trust in the miner for an ordering scheme that has no current possibility of proof.

If a miner start to shuffle the tx order, I'm sure the whole eco system will notice. Anyone with a node or other tx tracking software will be able to see it.

This binary thinking regarding security is part of how bitcoin got on the wrong track for many years. Craig held the position that security was an economic issue many years before he invented bitcoin, and was opposing other security experts that thought it was just a matter of cryptography and code.

Your arguments for waisting the useful data of transaction order for CTOR because it's not 100%, reminds me of Peter Todd's RBF. Zeroconf was destroyed because it was not 100% secure. And bitcoin ATM's were hacked with RBF.

If you can't step out of a theoretical binary mindset, I can't explain to you how this ordering data may have value in the future. Remember, bitcoin was never 100% or binary in terms of security. It's an economic game where honesty is rewarded.

EDIT:
I gave an example of the value of tx orders here:
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-1409#post-91105

Paying a (very lucky) miner in this example to shuffle the order of transactions is not very realistic. A big miner will be one of the largest financial institutions in the future. It would be like bribing Goldman Sachs to do something the whole ecosystem tracking transactions can see.

EDIT2: In practice, this would be done by sending a change message to all the miners when IBS is implemented. It would be very visible. Change messages will probably be very rare, because there are no obvious reasons other than fraud attempts to send them.

 

[Christoph Bergmann]

Yes, there is a widespread belief that it is OK to destroy the breaks of a car because driving will never be 100 percent secure anyway.

You will never know for sure if a miner ordered transactions in chronological order, and the chronology of all nodes is not identical. Does this make this information less reliable? Definitely. Does this make this information worthless? Definitely not.

 

[Norway]

Old clip of Craig talking about the economic aspect of security:

 

[cypherdoc]

I hope you bought the dip

 

[Norway]

@cypherdoc
It feels like a whale keeps BSV stable to some degree, but then it snaps out and track BTC movements. I like any form of decoupling. The investors need to wise up.

 

[theZerg]

Interesting discovery in bitcoind (sv) today. Apparently Bitcoin SV internally is maintaining two header branches at the same time, the BSV branch and the BCH branch. Only blocks on the BSV branch are accepted, but headers on both branches are being accepted and the BCH headers are being added to the CBlockIndex header tree memory structure.

When a new header comes in, its impossible to determine whether its a BTC, BCH or BSV block since all the headers are the same format. The only determining data is the hash of the previous header. A header that doesn't connect to the tip may be a valid larger work fork -- the software needs to follow it back to determine that its on an invalid block. This is why the software needs to keep track of the headers on other chains.

And since BCH and BSV share network ids (unlike BCH/BSV vs BTC), its very easy for accidental cross connections to present the wrong headers.

On another coding subject -- all your arguments about temporal tx order are awkward because bitcoind nodes don't put tx in the block in temporal order. Correct me if work on BSV has changed things but (AFAIR) the code puts them in order by fee, by dependencies and then by some random hash function deep in the bowels of std::map. I'm pointing this out because I think you guys should encourage work in this area to make SV tx temporally ordered by convention if not consensus and then see what interesting use cases emerge. It would not be a hard change... TX arrival times are stored in the mempool, just not used in the block construction.

 

[shadders]

We are removing fee ordering and a whole lot of other cruft. Once you assume all available txs will be included in every block there is no need to preferentially choose by fee order. Just validate then append to block template. Tons of things get easier when you can do this.

This has been heavily researched and is in progress but not complete yet.

 

[cypherdoc]

is there a long tern strategy for minfee?
[doublepost=1563620171][/doublepost]back up to 0.52.that's good.

 

[Norway]

On another coding subject -- all your arguments about temporal tx order are awkward because bitcoind nodes don't put tx in the block in temporal order. Correct me if work on BSV has changed things but (AFAIR) the code puts them in order by fee, by dependencies and then by some random hash function deep in the bowels of std::map. I'm pointing this out because I think you guys should encourage work in this area to make SV tx temporally ordered by convention if not consensus and then see what interesting use cases emerge. It would not be a hard change... TX arrival times are stored in the mempool, just not used in the block construction.

What is awkward is that you don't pick up on the IBS tech coming to BSV. When I'm discussing the benefits of temporal tx ordering, I don't claim that the Bitcoin SV node do it today. We are discussing the future of the real bitcoin that scales.

 

[SPAZTEEQ]

@shadders Why did satoshi not do this?

 

[lunar]

 

[cypherdoc]

0.555

Big Move
[doublepost=1563634348][/doublepost]BSV UP 33%

 

[Norway]

IBS is probably the most significant scaling tech for bitcoin ever invented. It would be nice if Thomas and I get some recognition for our paper in the future, but the most important thing is that the Bitcoin SV node is most likely going to implement it.
(Just to be clear: I don't know if @shadders & Co came up with the same idea independently or if they got inspiration from us.)

 

[cypherdoc]

if it can get over the previous high, look out:

 

[solex]

@solex, but as we know, the limit is not the essence, but the capacity that the software can handle...

Exactly right. Which is why BU development has continued focusing on improving on the software for scalability. It was us who first decided to take action once the headline block limit was increased beyond 1MB. All the various deeper issues in the code needed addressing which was why the Gigablock Testnet was launched in August 2017. That specific project did take a backseat in 2018, but is getting renewed work this year. However, scaling did not take a backseat as BU spent >$50k on our partnership with UMass on Graphene which uses IBLT. Graphene v2 is the most advanced software in existence for propagating very large blocks such as in the 100MB region where IBLT approaches theoretical limits for efficiency.
[doublepost=1563668863,1563668259][/doublepost]Bitcoin Unlimited 1.6.0.1 has just been released

https://www.reddit.com/r/btc/comments/cfmef9/bitcoin_unlimited_1601_has_just_been_released/

Note that BSV is not supported in this release, however BU versions 1.5.0.1 and 1.6.0.0 will remain compatible with BSV unless they get forked off by a future protocol-level change.

 

[cypherdoc]

getting close:

 

[Richy_T]

i don't know; there's these people called devs...poor (as in ragtag) devs who whine and beg for BCH donations all the while insisting on keeping 32MB while they tweak areas of the protocol needlessly, imo. and undermine the principles of PoW with checkpoints when they get threatened.

I don't know if BCH will manage to raise the block size limit before it's needed or whether they'll fall into the BTC trap. I think the problem BSV faces (other than the obvious) is the same as with BCH vs BTC and that is that it doesn't become an issue until it becomes an issue. While some can see a crisis coming ahead of time, it seems that a crucial majority are happy to keep on keeping on as long as the price is on the up even as the inevitable gets ever closer.

 

[cypherdoc]

what's inevitable and what is "it"?