Who said Google made a change to the algorithm because of ccn? I didn't see any statement by Google to that effect. It's far more likely that ccn made adjustments after seeing the impact of the algorithm and, after just a couple of days, the problems they had from not adjusting are beginning to dissipate thanks to a recent fix. That happens often with SEO, such as when webmasters don't see a Google statement about an algo update and instead see it first in Analytics results.

I appreciate the detailed explanation!!! So I do understand the concept and there is one part that is still somewhat unclear. Each node believes that it is working on the latest block in the chain until it receives a broadcast which it confirms and accept and realizes that it must create a new block based upon (perhaps) this latest block. At what point does forking actually begin to resolve -- a decision made by a node which is the longest chain? I'm assuming when miners begin to create and mine a new block, they perform a scan of the network to determine which chain is the longest. I'm not sure whether this is done by every block on the fly or there is some part of the protocol that would make such a request more efficient. At some point, the scanning results in the identification of the longest chain at that point in time.

Great point and thank you. I think I understood the original context and your answer is actually correct based upon the findings of a couple of studies too, albeit many are theoretical. Still, you can impact the chain with significantly less than 51% of the hash rate. I think there were mining pools which accomplished this in the 40s such as BTC, GHash. But the first block being mined means "discovery" of a transaction unless you scan the mempool. The first block sets the events in motion towards a resolution while a transaction in the mempool can stay in limbo and even undetectable for a while if you aren't looking.

Great reply and thank you! This was another issue I was investigating. It's amazing how things seem to work much of the time but I have to wonder whether it really does. Essentially in this instance a CPFP can distort the transaction ordering in theory. Target (the first spend) basically protects itself by doing so. But if a less savvy merchant is first and a more savvy merchant is second and uses CPFP, essentially the second savvy merchant has protected itself and made sure that the double spend is far more likely to resolve in their favor even though technically they were the later, double spend transaction. In essence, it seems that in order for a merchant to be safe on the network, it really requires a good amount of understanding how the system works or they could be in for a very large surprise. This concept of paying a transaction processor a premium is counterintuitive to the standardization of the centralized system.

Many thanks to all of you for being generous with your replies.

Understood - But the payee of the first transaction A (Target) will need to recheck periodically to see if the inputs in its transaction have been spent elsewhere. This doesn't happen automatically until a miner actually tries to verify the transaction, sees that the inputs have been spent already in transaction B, and broadcast to the network that transaction A is invalid. Target's software will need to periodically check both (a) the mempool for any other attempted spend of an input, and (b) the current state of the blockchain to see a confirmed spend of the same input.

-----------------------------------------------

I'm just going to stick with on-chain issues (not like legal stuff) So as per above, 1 confirm is like a magic number. Let's start with what moves the payment system forward - such as fee amount set by the user.

Well let's talk about the consumer for a moment. He does need to know what a transaction SHOULD cost. How much? I'm guessing that wallet software calculates fee averages based upon recent transactions to suggest what to use.

Back to transaction confirmations - I understand we are talking about the number of confirmations that a consensus of nodes having been polled agreed that this block (let's call it "B") is the next block on the blockchain (a long list of blocks ending with "A"). That should take at least 8-10 minutes per confirm (although I see videos of it taking much less than that such as on blockchain.info - how?)

The other concern I have is with is the potential for network latency, such as dealing in a country which doesn't have the greatest of network infrastructure (and perhaps a large number of bad acting nodes). If a consensus was reached that block B is the next block (...A-B) it's possible that nodes in a certain region may not see that another miner has presented A-C-D and my transaction, which was contained in B but not in C and D, can be tossed back to the mempool to start the cycle again and this situation can repeat itself. Thanks again very much.

First - many thanks for the reply and reference. I should probably have used a debit card since that works differently but in essence it's the same - that someone has guaranteed funds are there to be transferred. In a centralized payment system, at least the card issuer can check with the issuing bank that either (a) there are sufficient funds to transfer and a hold is immediately placed on those funds, or (b) that the card holder has sufficient amount under their credit limit and there is a pending transaction placed immediately.

In this example there isn't any guarantee that payment will even be processed. Hence I agree, the 1 transaction amount is very important! And for that I understand it to mean that a consensus of nodes have agreed that Block B is valid and to be added to the blockchain's current last block, let's call it Block A. And the longer the number of blocks confirmed, e.g. A-B-C-D... a decreasing risk exists that a Block B will be thrown out (and its transactions not also confirmed in another longer chain are put back into the mempool of unconfirmed transactions.) Do I have this correct?

Thanks much guys for the detailed responses, much appreciated! Please take my comments in an educational "devil's advocate" context since I am both still learning this complicated subject and my peers will be forceful with their arguments against rationales that I offer!

@nc50lc - Thanks! When you say third party payment processor, how would that work exactly, e.g. they will take a fee for payment and offer quicker processing time by taking the risk of a bad transaction by scaning mempools to identify double spends, etc.? If so, this seems very inefficient and beginning to add costs that might eventually approach costs from a traditional centralized model eventually? That's the objection I face here.

As to the LN, that appears to be a state/payment channel. This appears to make it less than ideal for individual transactions and primarily beneficial/practical for recurring transactions between merchant and customer on a channel level - but that takes place off-chain with money that is essentially required to be pre-cleared.


@pooya87 - Agreed, not a great idea with CCTV! And thanks for explanation of the logic about the size of the fee as an indicia of reliability. The situation I present isn't to be taken so literally, e.g. a $20 purchase a retail store because I can easily make the stakes higher - $2-5,000 at a furniture store, used car lot, etc. which people will try!

I'm looking at theoretically what can happen and not "probably won't but could" as the latter doesn't provide great confidence to many concerning financial transaction discussions. By comparison, in centralized systems, one can check available balance with ostensibly much greater certainty as well as providing a set expectation for transaction fees. Unless someone is really knowledgeable, there isn't any easy way to know what is an "acceptable" payment fee to bribe miners because it's dependent upon so many factors. It seems one really needs to rely upon third party processors.

I have a problem understanding how Bitcoin can ever be useful as a payment mechanism for a merchant in a retail store.

A block added to the blockchain consists of up to around 1,500 transactions which are verified (small block in kb). Apparently miners can choose larger fees over small. So you can do this: https://twitter.com/alexbosworth/status/1028031387201236992?lang=en

Essentially transaction A (at let's say at a Target retail store) has zero fees. Create a second transaction B a 30 minutes later (at Walmart) using the same unspent transaction but add a fee. Essentially B can be confirmed before a by miner 1 and be placed into a block before A is confirmed. If I am at either store, you have to wait a full hour to see which block will be the first one to be included on the blockchain. Yet the truth is that the first actual "spend" was A at the Target store. The second B at Walmart was, theoretically, the double spend. But what all these people seem to be focusing on is that Target wouldn't have lost money if they waited at least an hour (6 transactions) to determine whether they receive confirmations.

Problem 1 - this isn't true. If the transaction is stuck, you won't know a double spend occurred until finally it gets picked up by some miner and rejected and then that message relayed back to Target and the sender.

Problem 2 - the time it took to determine this is simply unacceptable, including for Walmart. You need to wait a long time AFTER your transaction is confirmed in a validly mined block. Even just 3 confirmation seems way too long - 30 minutes.