The necessity of "flash-back-pinning" in structure of transactions..

[mixoftix]

The flash-back-pinning is about a rule in PoCo [R1] that enforces the end user to include & sign the block number and its hash value of her last known chain (e.g. with 10 confirmation distance) in the structure of raw transactions. For flash-back-pinning we need to add two new fields “flash-back-block” and “flash-back-hash” after “timelock” field. So as timelock field provides a condition about after which block the transaction could be processed, the “flash-back-block” and “flash-back-hash” also provide us a condition about which chain this transaction belongs to [R2]:

Code:

Witness 2:
Locktime: 8c000000 (block 140)
Flash_back_block: 110
Flash_back_hash: 0000000000000000bd755ffe12f6ff47c3bc4940291e2ab310e69dc2c13fb4ac

With this potential improvement, 51% attacker can't use others' legitimate transactions of mempool for block fabrication in the hidden fork (so needs to generate many valid transactions for his hidden fork too). therefore, when an invalid fork involves, based on situation, with this rule:

1- Nodes could early stop a transaction in mempool (and the user understands that she has wrong chain info)
2- Miners also could exclude a payment on wrong chain from their candidate blocks
3- Receiver of payment also could ignore it, when she can't approve the Flash_back_hash in her chain

As an additional layer of protection, when a 51% attacker tries to broadcast a longer fork, the protocol checks the sum of coins-in-circulation among two/more forks. With same difficulty, the fake fork still needs to have the more coin-in-circulation to finalize the over-write process.

1- Is there any BIP/method similar to flash-back-pinning improvement proposal?
2- What is your assessment about flash-back-pinning in mitigating attacks?


[R1] https://bitcointalk.org/index.php?topic=5077722.0
[R2] https://medium.com/coinmonks/how-to-create-a-raw-bitcoin-transaction-step-by-step-239b888e87f2

[1618616854]

1618616854

[1618616854]

1618616854

[1618616854]

1618616854

[1618616854]

1618616854

[aliashraf]

I've been always a fan of committing to the chain by wallets for several reasons, as of your idea:

- There is no need for explicitly specifying the block height (your so-called flash-back-block field) as nodes could easily spot the target block, it is a waste of space.

- Speaking of space, It suffices to include like 8 last bytes of the block hash. To keep odds even higher, we could restrict inclusion of txns that refer to a block like more than one month earlier.

- I think there should be incentives for such a commitment and it suggests hashcash style work being included and accountend in a replace-fee-by-work fashion.

- Establishing an incentive mechanism helps to keep everything more smooth and implement it in a softer manner by making it an optional, new transaction format.

-An alternative approach would be committing to UTXO Merkle root instead of block hash.

There are a lot more to say ... will come back to this topic after a while at least for including links and references. 

[darosior]

Hi,

The flash-back-pinning is about a rule in PoCo

What is PoCo ? I think I remember you talked about it in a post I replied and I cannot retrieve any link about it.

1- Is there any BIP/method similar to flash-back-pinning improvement proposal?
2- What is your assessment about flash-back-pinning in mitigating attacks?

1- I haven't seen any but you can verify in the README of the bips repository.
2- I think we should evaluate the cost of doing it given the benefits.

Flash_back_block: 110
Flash_back_hash: 0000000000000000bd755ffe12f6ff47c3bc4940291e2ab310e69dc2c13fb4ac

If it's a 4bytes integer and a 32bytes hash it adds 36bytes to each transaction, which is an increase of about 14% of average tx size. It means less transactions in a block (or a block size increase), but we could reduce the cost with what proposed aliashraf.
However I think it's a good idea and it mays be more intended to PoS networks where a chain fork is cheap.

[mixoftix]

- Speaking of space, It suffices to include like 8 last bytes of the block hash. To keep odds even higher, we could restrict inclusion of txns that refer to a block like more than one month earlier.

True. this was just for better expressing the idea. in implementation, I have this format:

Code:

Locktime: 8c000000 (block 140)
Flashback: 110, bd755ffe12f6ff47c3bc4940291e2ab310e69dc2c13fb4ac (block#,block hash without 0)

which could shrink into your suggested version too:

Code:

Locktime: 8c000000 (block 140)
Flashback: 9dc2c13fb4ac (12 chars of block hash from right side)

What is PoCo ? I think I remember you talked about it in a post I replied and I cannot retrieve any link about it.

sorry for delay. I was busy with preparing the ppt file. please find it at:
https://bitcointalk.org/index.php?topic=5066624.0 (updated)

I have also changed the subject of topic for better results in search.

and it mays be more intended to PoS networks where a chain fork is cheap.

don't consider the bitcoin. unfortunately the PoW is fragile too when your crypto is not established yet.

[darosior]

sorry for delay. I was busy with preparing the ppt file. please find it at:
https://bitcointalk.org/index.php?topic=5077722.0

I think the correct link is https://bitcointalk.org/index.php?topic=5066624.0 

[ETFbitcoin]

After read your idea and do few research, i think it's good idea. Here are my opinion, comment and suggestion :

- It's hard to determine distance of blocks which is safe enough or last known "safe" block (at least without visit cryptocurrency news, forum or community)
- Determining "safe" distance of blocks automatically by wallet is extremely important, otherwise only users who check news or/and some technical knowledge who can enjoy the benefit
- It's not really useful for user with SPV wallet/nodes who never check news due to  SPV wallet/node vulnerability
- Assuming intentional hard-fork happen and forked coin "created" (which don't have replay protection) very recently, transaction is still vulnerable to replay attack since wallet might choose hash before hard-fork

- Unless you use SegWit script versioning, hard-fork is needed. But if you use SegWit script versioning, only user with upgraded client would enjoy the benefit
- Flash_back_block isn't needed since i doubt there are 2 or more block with same hash. Even if Flash_back_block only contain 12 char of hash from right side, there are 2.814749767x10¹⁴ combination. There's  no problem with searching hash with it's block height as bitcoin client already use block indexing
- For intentional hard-fork, forked coins could use sighash as replay protection which save user time

[mixoftix]

- It's hard to determine distance of blocks which is safe enough or last known "safe" block (at least without visit cryptocurrency news, forum or community)

My best candidate / suggestion for this concern is EXCHANGE CENTERS..

- Determining "safe" distance of blocks automatically by wallet is extremely important, otherwise only users who check news or/and some technical knowledge who can enjoy the benefit
- It's not really useful for user with SPV wallet/nodes who never check news due to  SPV wallet/node vulnerability
- Assuming intentional hard-fork happen and forked coin "created" (which don't have replay protection) very recently, transaction is still vulnerable to replay attack since wallet might choose hash before hard-fork
- Unless you use SegWit script versioning, hard-fork is needed. But if you use SegWit script versioning, only user with upgraded client would enjoy the benefit
- Flash_back_block isn't needed since i doubt there are 2 or more block with same hash. Even if Flash_back_block only contain 12 char of hash from right side, there are 2.814749767x10¹⁴ combination. There's  no problem with searching hash with it's block height as bitcoin client already use block indexing
- For intentional hard-fork, forked coins could use sighash as replay protection which save user time

OK
just added your comments to the documents of PoCo.. thank you.