Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update bip-0173.mediawiki #543

Closed
wants to merge 1 commit into from
Closed

Update bip-0173.mediawiki #543

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
20 changes: 20 additions & 0 deletions bip-0173.mediawiki
View file
Open in desktop
Expand Up @@ -362,3 +362,23 @@ separator).
This document is inspired by the [https://rusty.ozlabs.org/?p=578 address proposal] by Rusty Russell, the
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-February/004402.html base32] proposal by Mark Friedenbach, and had input from Luke Dashjr,
Johnson Lau, Eric Lombrozo, Peter Todd, and various other reviewers.



==Discussion==

Bech sounds nice as a format outside of the context, but the letters SEG would fit the use case in bitcoin better.

Like:

seg1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7k7grplx

OR

SEG1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7k7grplx

The SEG prefix Would give a visual confiramtion that the transaction will be validaded/settled in the segregated layer of the blockchain.

I think it would also provide clarity, in case that the other parts of bitcoin will want to use the bech fomat. So that there is no mix-up with the potential future use cases of the bech adresses.

Let's say that there will be segregated witness transactions, then there will be the script transaction, then the transactions between the separated layers. If they all end-up using the bech format, then the adress would better start with something that is realted to the use case, instead of BC.