public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: "Kenshiro []" <tensiam@hotmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
Date: Thu, 14 Feb 2019 21:14:03 +0000	[thread overview]
Message-ID: <HE1PR10MB183491C8B04893E0F9B9A250A6670@HE1PR10MB1834.EURPRD10.PROD.OUTLOOK.COM> (raw)

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

Greetings,

I think extension blocks could be optional, and it could be many different extension blocks with different functionalities like Confidential Transactions or smart contracts. Only the interested nodes would enable this extension blocks, the rest would see only the classic blockchain without extension blocks. So it's not a matter of "old" and "new" nodes, all are updated nodes with extension blocks enabled or not. The only ones that need to understand the protocols of all existing extension blocks are the miners, which must verify that transactions from "anyone-can-spend" to a "classic" address are legal.

So this is what a node with all extension blocks disabled would see in the blockchain:

  *   Classic address to classic address: as always
  *   Classic address to extension block address: transaction to "anyone-can-spend"
  *   Extension block address to classic address: transaction from "anyone-can-spend"
  *   Extension block address to extension block address: it doesn't see it because it doesn't download the extension blocks, only the main blocks.

All coins that are in extension blocks are also in the "anyone-can-spend" address of the main blocks, so basic nodes are aware of the total number of coins. It's totally safe.

So for the particular case of Confidential Transactions, it would work as explained. The CT transaction details would be in the extension block which could have the same size as the main block so the total size of the blockchain (main blocks + extension blocks) would be double.

With this method bitcoin could add new features without losing the "store of value" property, as the base protocol never changes. Again, maybe I'm missing some technical detail here, I'm still learning 😊

Regards



[-- Attachment #2: Type: text/html, Size: 4635 bytes --]

next             reply	other threads:[~2019-02-14 21:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14 21:14 Kenshiro [] [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-02-08 10:12 Kenshiro []
2019-02-11  4:29 ` ZmnSCPxj
2019-02-11 10:19   ` Kenshiro []
2019-02-12 17:27   ` Trey Del Bonis
2019-02-14 22:32   ` Hampus Sjöberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HE1PR10MB183491C8B04893E0F9B9A250A6670@HE1PR10MB1834.EURPRD10.PROD.OUTLOOK.COM \
    --to=tensiam@hotmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox