Bitcoin Forum
November 13, 2019, 05:12:50 PM *
News: 10th anniversary art contest
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: The necessity of "flash-back-pinning" in structure of transactions..  (Read 232 times)
mixoftix
Member
**
Offline Offline

Activity: 104
Merit: 145

..


View Profile WWW
December 25, 2018, 02:42:56 PM
Merited by ETFbitcoin (4), aliashraf (2), darosior (1)
 #1

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



من مست و تو دیوانه، مارا که برد خانه!؟
translation from Persian:
I am drunk and you are insane, who will take us home!? --Rumi
1573665170
Hero Member
*
Offline Offline

Posts: 1573665170

View Profile Personal Message (Offline)

Ignore
1573665170
Reply with quote  #2

1573665170
Report to moderator
1573665170
Hero Member
*
Offline Offline

Posts: 1573665170

View Profile Personal Message (Offline)

Ignore
1573665170
Reply with quote  #2

1573665170
Report to moderator
The Bitcoin Forum is turning 10 years old! Join the community in sharing and exploring the notable posts made over the years.
1573665170
Hero Member
*
Offline Offline

Posts: 1573665170

View Profile Personal Message (Offline)

Ignore
1573665170
Reply with quote  #2

1573665170
Report to moderator
1573665170
Hero Member
*
Offline Offline

Posts: 1573665170

View Profile Personal Message (Offline)

Ignore
1573665170
Reply with quote  #2

1573665170
Report to moderator
aliashraf
Hero Member
*****
Offline Offline

Activity: 952
Merit: 706

always remember, remember the cause


View Profile WWW
December 25, 2018, 03:17:21 PM
Merited by ETFbitcoin (2)
 #2

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.  Wink
darosior
Full Member
***
Online Online

Activity: 196
Merit: 223



View Profile WWW
December 25, 2018, 08:39:31 PM
 #3

Hi,

Quote
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.

Quote
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.
Quote
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
Member
**
Offline Offline

Activity: 104
Merit: 145

..


View Profile WWW
December 25, 2018, 09:44:40 PM
Last edit: December 25, 2018, 10:46:50 PM by mixoftix
Merited by ETFbitcoin (1)
 #4

- 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.

من مست و تو دیوانه، مارا که برد خانه!؟
translation from Persian:
I am drunk and you are insane, who will take us home!? --Rumi
darosior
Full Member
***
Online Online

Activity: 196
Merit: 223



View Profile WWW
December 25, 2018, 10:37:57 PM
Merited by mixoftix (1)
 #5

Quote
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  Wink

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1820
Merit: 2079

Use SegWit and enjoy lower fees.


View Profile WWW
February 10, 2019, 04:02:53 PM
Merited by mixoftix (1)
 #6

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.814749767x1014 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
Member
**
Offline Offline

Activity: 104
Merit: 145

..


View Profile WWW
March 15, 2019, 10:42:07 PM
 #7

- 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.814749767x1014 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.

من مست و تو دیوانه، مارا که برد خانه!؟
translation from Persian:
I am drunk and you are insane, who will take us home!? --Rumi
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!