Gold collapsing. Bitcoin UP.

[cypherdoc]

oops:

what a dupe:

https://news.bitcoin.com/lightning-networks-antifraud-methods-inferior-to-nakamoto-consensus-research-shows/
[doublepost=1563408378][/doublepost]this is rich. now LN pumpers like Lopp want you to run a watchtower, lol. how much hardware do you need to run this shit? getting upwards of $20,000

Jameson Lopp’s defense against third parties who are bad actors using watchtowers is that you can run your own watchtower.

 

[cypherdoc]

>Sorry to not be a maximalist guys, but future is risky and you deal with risks by keeping (technological) options open.

or, by scaling rapidly. Bitcoin is behind schedule. the original hope many of us OG's had was for rapid adoption worldwide before gvts had a chance to react. this is why the 1MB4EVA policy was a huge red flag that caused me to speak out so early against Blockstream. here we are 2019 and one can wonder if gvt has won. fiat payments of all kinds have gotten easier, faster, and more liquid as providers have had time to adapt to the threat. is it too late? i don't think so but it's getting close. BSV with unlimited blocksizes is our only hope, imo. the other reason a locked down protocol is advantageous is not only to protect against dev corruption but gvt takeover. if the code is reproducible and accessible worldwide and not dependent on constant q6mo development (at least for the next 1-2 decades before QC), then it's chances of surviving are greater. can you imagine gvts rounding up all known BCH devs? it'd be all over. in a week we go to 2GB and then next Feb unlimited with the lockdown. the hope is that BSV explodes as a result as after that, it can't be touched. afaic, rounding up nChain devs would then not matter.

so in case i wasn't clear, BTC, BCH, & BU keep saying "what's the rush? who needs scaling today when there isn't demand? we got plenty of time." wrong, wrong, wrong. you're running out of time on two levels. first, fiat payment providers are hot on your tail improving their services and gvt is probably getting ready to crack down. second, with that kinda attitude, no one significant (users, investors, merchants, institutions) is going to move first to adopt your cripplecoin. yes, 32MB is crippled esp with the devs attitudes. personally, i like my chances with BSV, who's taking the opposite approach to rapidly scaling and getting ready to lockdown the protocol come February and then get the hell outta the way.

 

[Norway]

this is rich. now LN pumpers like Lopp want you to run a watchtower, lol. how much hardware do you need to run this shit? getting upwards of $20,000

If you run a watchtower that is online 24/7, you don't have to be online all the time to use Lightning Network

 

[cypherdoc]

except that there's this thing called Bitcoin. oh wait...

 

[torusJKL]

this is rich. now LN pumpers like Lopp want you to run a watchtower, lol. how much hardware do you need to run this shit? getting upwards of $20,000

Jameson Lopp’s defense against third parties who are bad actors using watchtowers is that you can run your own watchtower.

Isn't a watchtower a full node that is available 24/7?
And if that is the case what is the difference of running your own LN node vs running a LN watchtower?

 

[Christoph Bergmann]

I hate to say this, but I think Theymos is right to be prudent regarding governments:

That's why I think the "respect the law and everything will be ok" mantra professed by Zangelbert is too naively optimistic.

Governments cannot be trusted blindly, humanity should be prepared to adverse scenarios, just in case.

And that doesn't mean I think implementing privacy on BTC or even BSV is the way to go, the only rational response to this kind of threat is the increase use of Monero.

Sorry to not be a maximalist guys, but future is risky and you deal with risks by keeping (technological) options open.

Call me crazy but I think BTC, BSV, XMR, ETH, and maybe some others blockchain, may all have their utility for humanity in the future.

Yes, exactly. Btc, bsv, eth and xmr would be my basket too. Maybe bch as a backup in case nchain fucks up bsv before the protocol is locked.

I also think the trust in law is sometimes too much win bsv community. But most seem to have the standing that bitcoin should not be ruled by law, but does not replace it. It interacts with law, upgrading the position of citizens.

I had a long discussion with a sane German bitcoin maximalist. He is annoyed of the cypherpunks and thinks there is contradiction between them and citizenship. He wants bitcoin to make democracy and basic rights stronger, while he thinks cypherpunks want it to disappear in anonymity and the destruction of the state.

So, basically, bsv should be the only coin for him.

 

[cypherdoc]

LN pumper ripped to shreds :

 

[trinoxol]

Yes, exactly. Btc, bsv, eth and xmr would be my basket too. Maybe bch as a backup in case nchain fucks up bsv before the protocol is locked.

I'm personally not worried that the BSV protocol could be messed up. But BCH is still in play:

Fees on BTC will rise. When masses of users turn away because of that, what currency will they flock to? It might very well be BCH for reputation reasons.

I hope we can avoid a situation where BCH takes the market for multiple years until BSV finally wins. BSV might even lose the payment network permanently and win only the data storage use cases.

It's not like BCH won't raise the block size when they have to. BCH will forever ensure cheap, reliable transactions.

The rise of fees is, in my view, essentially the only thing that can kill the leading currency. For that reason, BCH is still in play.

 

[cypherdoc]

Isn't a watchtower a full node that is available 24/7?
And if that is the case what is the difference of running your own LN node vs running a LN watchtower?

the way it reads to me, and given how we know that core always recommends running your own full nodes, it sounds like Lopp also recommends running your own watch towers on top of all that. probably just in case your full nodes go down. it's an over engineered cluster fuck, I know.

 

[cypherdoc]

It's not like BCH won't raise the block size when they have to. BCH will forever ensure cheap, reliable transactions.

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.

they just can't seem to accept the idea that BCH and BTC is not theirs. that, just b/c they are coders, doesn't mean they get to rule a new form of money dependent on code. so they grab the github and impose new rules and regulations that cripple the original vision and then insist on getting paid for work that more or less doesn't need to be done or outright subverts future miner fees. i don't recall anyone else describing Bitcoin as a public good before i did somewhere back in 2013-14, but that's what it is, a public good.

the simple reason i take this position is that by any measure, i know that the original Bitcoin has not been allowed to play out. you can tweak and twist certain principles and come up with FUD about "centralization" theories with big block limits, but when i read carefully that which Satoshi has written in various emails, chats, and posts, it's clear he thought Bitcoin can scale indefinitely onchain via big blocks. everything we saw for the years leading up to hitting the 1MB ceiling and before segwit confirms that it works. all BSV is doing is allowing the original experiment to continue w/o directly corrupting the original protocol to nChain's benefit. patents sure. but only for layered applications. the base protocol is still a public good and will legally allow even a hard fork if necessary.

i honestly think protocol devs either willfully or subconsciously like to stay relevant either for notoriety or flat out getting paid. Blockstream is the worst representation of a corporate formation of core devs to exploit miner fees. i see Amaury's whining/begging as a big red flag and still predict a Blockstream 2.0. locking the protocol down is the last thing protocol devs want as it renders them, at least for many years, irrelevant. i say get outta the way and become an application dev. but then you'd have to compete. and you wouldn't be the center of attention.

 

[79b79aa8]

BCH is still in play.

séchet and those left around him v. nChain is like children v. men.

 

[rocks]

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. This is on version 0.2.0

Discovered this when I found a massive multi-month deep active fork in a project I'm building, at first I thought I had a bug, took a bit to discover that the 2nd (longer but inactive) branch was BCH headers. @shadders if you're here that probably should be fixed FYI.

Here is an internal trace of bitcoind block and header acceptance showing this. This node started ~1 hour behind. On startup:

• It first downloaded and accepted BCH headers 59189X
• It then downloaded and accepted BSV headers 59172X
• It then downloaded and accepted new BSV 59172X blocks, but not 59189X BCH blocks
• From there it receives new blocks as they are found
  • New BSV blocks accept a header and then the new block
  • New BCH blocks accept a header (but not a block)

It is correct that the BCH blocks are rejected but pollutes the blockindex structures by accepting their headers in-memory.

Anyway, I thought it was an interesting find so wanted to share.

2019-07-18 20:56:04.726443 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591894 hash 0000000000000000002bb5dd01557259db349cef42927736ca3f09d3219e8b67
2019-07-18 20:56:04.726817 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591895 hash 00000000000000000430e9787bc4614a2e6147496cbc5fbe15d1a9e1166868b5
2019-07-18 20:56:04.727136 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591896 hash 0000000000000000016939c024d327a6aa3d3bcbd7364412640d13dd65021eba
2019-07-18 20:56:04.727460 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591897 hash 000000000000000000421e5c89a07b622b5565071c0c59e2c8c91b4ea486e632
2019-07-18 20:56:16.293678 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591725 hash 00000000000000000837ccdaef500449bdad22992f87bf58e2bb25fcc83155a9
2019-07-18 20:56:16.293939 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591726 hash 00000000000000000416d28dd6550af7bd2dec2abda3a3d5fd0e212eb552641e
2019-07-18 20:56:16.294220 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591727 hash 0000000000000000027016b2b0b0dbded162ee29e8c11759f9b2b300568c0f6c
2019-07-18 20:56:16.294485 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591728 hash 0000000000000000051378698ca1b5c70a98a445ecc4d9dc884a0a5514298341
2019-07-18 20:56:16.294679 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591729 hash 000000000000000005ad429b7980d30024675bae0115198eb9a61f2ac394c425
2019-07-18 20:56:17.095926 -------> AcceptBlock          <------- NewBlock (pindex    height 591725 hash 00000000000000000837ccdaef500449bdad22992f87bf58e2bb25fcc83155a9
2019-07-18 20:56:19.278521 -------> AcceptBlock          <------- NewBlock (pindex    height 591726 hash 00000000000000000416d28dd6550af7bd2dec2abda3a3d5fd0e212eb552641e
2019-07-18 20:56:19.297958 -------> AcceptBlock          <------- NewBlock (pindex    height 591727 hash 0000000000000000027016b2b0b0dbded162ee29e8c11759f9b2b300568c0f6c
2019-07-18 20:56:19.365326 -------> AcceptBlock          <------- NewBlock (pindex    height 591728 hash 0000000000000000051378698ca1b5c70a98a445ecc4d9dc884a0a5514298341
2019-07-18 20:56:19.424367 -------> AcceptBlock          <------- NewBlock (pindex    height 591729 hash 000000000000000005ad429b7980d30024675bae0115198eb9a61f2ac394c425
2019-07-18 21:06:08.812093 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591898 hash 00000000000000000116d0ea4b013f87ef9128edf13f50db27a409c83e9e7898
2019-07-18 21:13:29.559167 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591730 hash 000000000000000000ad5c86cf1c981cb02aa1cc7e56de270ec84b9e187b0e96
2019-07-18 21:13:31.879454 -------> AcceptBlock          <------- NewBlock (pindex    height 591730 hash 000000000000000000ad5c86cf1c981cb02aa1cc7e56de270ec84b9e187b0e96
2019-07-18 21:13:33.061976 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591731 hash 000000000000000002ef7a7877f4ffc9abb62bf80e0d46c85c125d2190bdf60b
2019-07-18 21:13:33.312821 -------> AcceptBlock          <------- NewBlock (pindex    height 591731 hash 000000000000000002ef7a7877f4ffc9abb62bf80e0d46c85c125d2190bdf60b
2019-07-18 21:16:25.491044 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591732 hash 00000000000000000051dfb643da8cc6a5758be2691e27cfe6da61a7fbf307de
2019-07-18 21:16:26.234549 -------> AcceptBlock          <------- NewBlock (pindex    height 591732 hash 00000000000000000051dfb643da8cc6a5758be2691e27cfe6da61a7fbf307de
2019-07-18 21:17:44.990051 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591733 hash 000000000000000007135ec4d75e9cfa0e3a76de97ad589684512df936c90acd
2019-07-18 21:17:45.239047 -------> AcceptBlock          <------- NewBlock (pindex    height 591733 hash 000000000000000007135ec4d75e9cfa0e3a76de97ad589684512df936c90acd
2019-07-18 21:17:56.085952 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591899 hash 000000000000000002ae120922d8cf3cb1e8a53964ea4b0f85ac539fc48dd379
2019-07-18 21:30:44.801865 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591900 hash 00000000000000000012846679fe965046f3e89277e3781fe57d78c6482efc56
2019-07-18 21:39:54.500246 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591734 hash 000000000000000000d58b8375cef4eeb26096c06afa4cdd0fc5eb2c02a4c238
2019-07-18 21:39:55.152368 -------> AcceptBlock          <------- NewBlock (pindex    height 591734 hash 000000000000000000d58b8375cef4eeb26096c06afa4cdd0fc5eb2c02a4c238
2019-07-18 21:40:02.387567 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591901 hash 0000000000000000026f056542c75535c2c243bb5a4e13b734fcc310d689023f
2019-07-18 21:41:14.178544 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591735 hash 0000000000000000092e0004d239def0ff0e3e3bfdf1e95e1d75b04425660005
2019-07-18 21:41:14.179680 -------> AcceptBlock          <------- NewBlock (pindex    height 591735 hash 0000000000000000092e0004d239def0ff0e3e3bfdf1e95e1d75b04425660005
2019-07-18 21:42:14.705604 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591902 hash 000000000000000001bb8a7702ac820ec18b013e965671ef32f241592f6cbf40
2019-07-18 21:43:04.741152 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591903 hash 000000000000000002bdb4d2a143d8772df8412a238326ed7c0f5f893a21a865
2019-07-18 21:43:11.123789 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591904 hash 000000000000000003449115cecb3000cdd12dad3153454d1312d427227b506b
2019-07-18 21:54:05.852280 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591905 hash 000000000000000001e33e2eb32b9229624e3222a32548155a030147a4c6593b

 

[Erdogan]

it's amazing to watch the extent to which even old timers are contorting themselves to call themselves big blockists:


the only conclusion you can draw from an interchange like this is that BCH, BU, and BTC do not trust miners. which is really odd given that miners are the only ones being paid directly by the protocol and have the most resources at risk invested into the system not only in terms of money but also work.

Why is it that I can take myself all the way back to 2011 to rehash old arguments in defense of miners?

Lol I saw that

 

[Epilido]

CTOR is a data loss process

What type of data is lost with any particular type or ordering?

As I understand (and please correct me if I am wrong) miners are free to order the transaction in a block in any order. So it could be first seen or highest value first or lowest value first.

If the miners can order however they want how is data lost?

 

[trinoxol]

CTOR is an ordering that is enforced by the consensus rules. It is not optional. TTOR is enforced as well but it far more lenient.

In my view, it would be best to have no enforced ordering.

 

[Zarathustra]

"Sorry, no techno babble"

Nice thread

 

[Norway]

What type of data is lost with any particular type or ordering?

Good question. The order that a miner receive transactions is lost if the data is sorted lexicographically.

Imagine you stand in the finish area of a marathon and write down just the names (not the time) of the runners as they cross the finishing line. You get a list with the winner of the race on top. If you sort that list lexicographically and store it, you will not be able to tell who came in first place, second place etc later in time. That data is lost.

As I understand (and please correct me if I am wrong) miners are free to order the transaction in a block in any order. So it could be first seen or highest value first or lowest value first.

On BSV, miners can use the order they choose in a block. Miners do not receive transactions in the exact same order, so there is no global "correct" order. The order is relative to the individual miner. I assume this is why a specific order is not required by the consensus rules. The Bitcoin SV node software is AFAIK going to store transactions (mostly) in the order they are received when they implement a refinded version of IBS. From what I understood of @shadders talk on developer day in Toronto, they will allow reordering/changing of specific transactions with specific messages to other miners. I believe this is implemented so the original economic model/rules are not changed. Perhaps to get the nod from CSW

If the miners can order however they want how is data lost?

It boils down to probability, like most things in bitcoin. If most miners order the transactions in the order they see the transactions, you have a high probability that a transaction ordered before another transaction most likely was initiated first. With CTOR, you have absolutly no clue about the order of events (for transactions not directly related with dependency).

 

[cypherdoc]

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. This is on version 0.2.0

Discovered this when I found a massive multi-month deep active fork in a project I'm building, at first I thought I had a bug, took a bit to discover that the 2nd (longer but inactive) branch was BCH headers. @shadders if you're here that probably should be fixed FYI.

Here is an internal trace of bitcoind block and header acceptance showing this. This node started ~1 hour behind. On startup:

• It first downloaded and accepted BCH headers 59189X
• It then downloaded and accepted BSV headers 59172X
• It then downloaded and accepted new BSV 59172X blocks, but not 59189X BCH blocks
• From there it receives new blocks as they are found
  • New BSV blocks accept a header and then the new block
  • New BCH blocks accept a header (but not a block)

It is correct that the BCH blocks are rejected but pollutes the blockindex structures by accepting their headers in-memory.

Anyway, I thought it was an interesting find so wanted to share.

2019-07-18 20:56:04.726443 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591894 hash 0000000000000000002bb5dd01557259db349cef42927736ca3f09d3219e8b67
2019-07-18 20:56:04.726817 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591895 hash 00000000000000000430e9787bc4614a2e6147496cbc5fbe15d1a9e1166868b5
2019-07-18 20:56:04.727136 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591896 hash 0000000000000000016939c024d327a6aa3d3bcbd7364412640d13dd65021eba
2019-07-18 20:56:04.727460 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591897 hash 000000000000000000421e5c89a07b622b5565071c0c59e2c8c91b4ea486e632
2019-07-18 20:56:16.293678 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591725 hash 00000000000000000837ccdaef500449bdad22992f87bf58e2bb25fcc83155a9
2019-07-18 20:56:16.293939 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591726 hash 00000000000000000416d28dd6550af7bd2dec2abda3a3d5fd0e212eb552641e
2019-07-18 20:56:16.294220 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591727 hash 0000000000000000027016b2b0b0dbded162ee29e8c11759f9b2b300568c0f6c
2019-07-18 20:56:16.294485 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591728 hash 0000000000000000051378698ca1b5c70a98a445ecc4d9dc884a0a5514298341
2019-07-18 20:56:16.294679 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591729 hash 000000000000000005ad429b7980d30024675bae0115198eb9a61f2ac394c425
2019-07-18 20:56:17.095926 -------> AcceptBlock          <------- NewBlock (pindex    height 591725 hash 00000000000000000837ccdaef500449bdad22992f87bf58e2bb25fcc83155a9
2019-07-18 20:56:19.278521 -------> AcceptBlock          <------- NewBlock (pindex    height 591726 hash 00000000000000000416d28dd6550af7bd2dec2abda3a3d5fd0e212eb552641e
2019-07-18 20:56:19.297958 -------> AcceptBlock          <------- NewBlock (pindex    height 591727 hash 0000000000000000027016b2b0b0dbded162ee29e8c11759f9b2b300568c0f6c
2019-07-18 20:56:19.365326 -------> AcceptBlock          <------- NewBlock (pindex    height 591728 hash 0000000000000000051378698ca1b5c70a98a445ecc4d9dc884a0a5514298341
2019-07-18 20:56:19.424367 -------> AcceptBlock          <------- NewBlock (pindex    height 591729 hash 000000000000000005ad429b7980d30024675bae0115198eb9a61f2ac394c425
2019-07-18 21:06:08.812093 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591898 hash 00000000000000000116d0ea4b013f87ef9128edf13f50db27a409c83e9e7898
2019-07-18 21:13:29.559167 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591730 hash 000000000000000000ad5c86cf1c981cb02aa1cc7e56de270ec84b9e187b0e96
2019-07-18 21:13:31.879454 -------> AcceptBlock          <------- NewBlock (pindex    height 591730 hash 000000000000000000ad5c86cf1c981cb02aa1cc7e56de270ec84b9e187b0e96
2019-07-18 21:13:33.061976 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591731 hash 000000000000000002ef7a7877f4ffc9abb62bf80e0d46c85c125d2190bdf60b
2019-07-18 21:13:33.312821 -------> AcceptBlock          <------- NewBlock (pindex    height 591731 hash 000000000000000002ef7a7877f4ffc9abb62bf80e0d46c85c125d2190bdf60b
2019-07-18 21:16:25.491044 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591732 hash 00000000000000000051dfb643da8cc6a5758be2691e27cfe6da61a7fbf307de
2019-07-18 21:16:26.234549 -------> AcceptBlock          <------- NewBlock (pindex    height 591732 hash 00000000000000000051dfb643da8cc6a5758be2691e27cfe6da61a7fbf307de
2019-07-18 21:17:44.990051 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591733 hash 000000000000000007135ec4d75e9cfa0e3a76de97ad589684512df936c90acd
2019-07-18 21:17:45.239047 -------> AcceptBlock          <------- NewBlock (pindex    height 591733 hash 000000000000000007135ec4d75e9cfa0e3a76de97ad589684512df936c90acd
2019-07-18 21:17:56.085952 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591899 hash 000000000000000002ae120922d8cf3cb1e8a53964ea4b0f85ac539fc48dd379
2019-07-18 21:30:44.801865 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591900 hash 00000000000000000012846679fe965046f3e89277e3781fe57d78c6482efc56
2019-07-18 21:39:54.500246 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591734 hash 000000000000000000d58b8375cef4eeb26096c06afa4cdd0fc5eb2c02a4c238
2019-07-18 21:39:55.152368 -------> AcceptBlock          <------- NewBlock (pindex    height 591734 hash 000000000000000000d58b8375cef4eeb26096c06afa4cdd0fc5eb2c02a4c238
2019-07-18 21:40:02.387567 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591901 hash 0000000000000000026f056542c75535c2c243bb5a4e13b734fcc310d689023f
2019-07-18 21:41:14.178544 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591735 hash 0000000000000000092e0004d239def0ff0e3e3bfdf1e95e1d75b04425660005
2019-07-18 21:41:14.179680 -------> AcceptBlock          <------- NewBlock (pindex    height 591735 hash 0000000000000000092e0004d239def0ff0e3e3bfdf1e95e1d75b04425660005
2019-07-18 21:42:14.705604 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591902 hash 000000000000000001bb8a7702ac820ec18b013e965671ef32f241592f6cbf40
2019-07-18 21:43:04.741152 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591903 hash 000000000000000002bdb4d2a143d8772df8412a238326ed7c0f5f893a21a865
2019-07-18 21:43:11.123789 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591904 hash 000000000000000003449115cecb3000cdd12dad3153454d1312d427227b506b
2019-07-18 21:54:05.852280 -------> AcceptBlockHeader    <------- NewHeader(pindexNew height 591905 hash 000000000000000001e33e2eb32b9229624e3222a32548155a030147a4c6593b

what effects do you think this has?

 

[Epilido]

It boils down to probability, like most things in bitcoin. If most miners order the transactions in the order they see the transactions, you have a high probability that a transaction ordered before another transaction most likely was initiated first.

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.

 

[trinoxol]

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.