Bitcoin Forum
November 14, 2024, 01:33:33 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 [8] 9 »  All
  Print  
Author Topic: An easy way to remember a bitcoin address  (Read 15139 times)
Nicolas Dorier (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 662


View Profile
March 08, 2015, 05:24:26 PM
 #141

Quote
If you can't create an address you like, Then why don't you just remember the priv key? "which you can clearly remember".
Not the point of this BIP. The goal is to remember a payment destination that you can share with others.
If you attempt to create a private key that can be remembered, then you will loose your money. Simple as that.

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
onemorexmr
Sr. Member
****
Offline Offline

Activity: 252
Merit: 251



View Profile
March 08, 2015, 05:29:30 PM
 #142

I like OpenAlias for this.

its coin agnostic and uses DNS: https://openalias.org/

but it doesnt solve the address-reuse problem gmaxwell mentioned.

XMR || Monero || monerodice.net || xmr.to || mymonero.com || openalias.org || you think bitcoin is fungible? watch this
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
March 08, 2015, 05:32:59 PM
 #143


According to blockchain.info wallet, it's not. I imported it and wallet accepted it. But I didn't try to send btc yet.
edit: I've sent some btc to it; https://blockchain.info/tx/eb982663b019abc759b7b1853efda29786159ddc98013ed6058104f94d7e6563
if you like you can import it and clear the balance Wink



The private key is certainly invalid. One more reason NOT to use blockchain.info wallet (and they are delisted from bitcoin.org already)

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Nicolas Dorier (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 662


View Profile
March 08, 2015, 05:33:34 PM
 #144

Quote
I like OpenAlias for this.

its coin agnostic and uses DNS: https://openalias.org/

but it doesnt solve the address-reuse problem gmaxwell mentioned.
It does please re-read what we talked about.
You solution involve trust relationship.

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
onemorexmr
Sr. Member
****
Offline Offline

Activity: 252
Merit: 251



View Profile
March 08, 2015, 05:37:22 PM
 #145

Quote
I like OpenAlias for this.

its coin agnostic and uses DNS: https://openalias.org/

but it doesnt solve the address-reuse problem gmaxwell mentioned.
It does please re-read what we talked about.
You solution involve trust relationship.

its just a dns record.
dnssec may be used by shops and private persons may use namecoin.

dnssec still has a trust relationship; bit domains dont.

XMR || Monero || monerodice.net || xmr.to || mymonero.com || openalias.org || you think bitcoin is fungible? watch this
Nicolas Dorier (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 662


View Profile
March 08, 2015, 05:46:58 PM
 #146

This is just not the point of this BIP. We don't want any registration process on another alt chain nor alt database (DNS), and want to be verifiable by current SPV wallet easily.

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
onemorexmr
Sr. Member
****
Offline Offline

Activity: 252
Merit: 251



View Profile
March 08, 2015, 05:52:52 PM
 #147

This is just not the point of this BIP. We don't want any registration process on another alt chain nor alt database (DNS), and want to be verifiable by current SPV wallet easily.

i don't want to criticize your work and i think it is very interesting from a technical point of view.

its just not usable (for me).
all "normal" persons wont never remember multiple words nor an address (they would ctrl-c both).
add the address-reuse problem to this and please tell me: what do you actually want to solve (means: use-case)?

XMR || Monero || monerodice.net || xmr.to || mymonero.com || openalias.org || you think bitcoin is fungible? watch this
Nicolas Dorier (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 662


View Profile
March 08, 2015, 05:54:46 PM
 #148

Quote
all "normal" persons wont never remember multiple words nor an address (they would ctrl-c both).
add the address-reuse problem to this and please tell me: what do you actually want to solve (means: use-case)?
The response to this question is the same than this one : "Why everybody remember its own mobile phone number ?"
For those same reason we create this BIP.

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1086


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 08, 2015, 05:56:58 PM
 #149

I pointed out a simple use case as to why I like this idea.

You are "out and about" and have an opportunity to say exchange some BTC for some fiat (person to person) but you don't have your computer handy.

If you can use a system like this then you can find a payment address just from memory (rather than copy and paste).

Firstbits was a way to do this (but has now been abandoned) so this is another idea (and yes I am well aware that re-use of addresses is not advised).

Of course if we all have apps we trust on mobile phones to store our payment addresses the point is probably mute (so just how needed this idea might be is hard to say).

But still if you have two separate computers (and no ability to use QR codes) then having an easier way to "type in the address" can be useful.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
onemorexmr
Sr. Member
****
Offline Offline

Activity: 252
Merit: 251



View Profile
March 08, 2015, 06:01:05 PM
 #150

maybe its just me, but i would not trust my brain remembering the words correctly.
a checksum (as planned) is a good idea.

i just compare it to the amount of phone calls i get from people who didn't intend to call me in the first place.

but i am unsure: so lets see. a BIP is not a bad idea at all; if it gets accepted by "normal" people everything is fine. a solution only for btc-enthusiasts seems unnecessary.

XMR || Monero || monerodice.net || xmr.to || mymonero.com || openalias.org || you think bitcoin is fungible? watch this
Nicolas Dorier (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 662


View Profile
March 08, 2015, 06:07:02 PM
 #151

Quote
Of course if we all have apps we trust on mobile phones to store our payment addresses the point is probably mute (so just how needed this idea might be is hard to say).
Even with that, it won't work.
Wallet providers would not develop coherent integration between all trusted payment address stores of the market.
The matter is different when trust relationship is removed, we can get a coherency accross all bitcoin applications.

If your payment destination on Coinbase is "CIYAM". Sure you can remember CIYAM easily.
However, your payer must use a software that integrate with Coinbase.

By only using the blockchain + compact proof, then all software supporting Bitcoin can support this protocol without any additional trust need to multiple trust parties.

Quote
I pointed out a simple use case as to why I like this idea.

You are "out and about" and have an opportunity to say exchange some BTC for some fiat (person to person) but you don't have your computer handy.

If you can use a system like this then you can find a payment address just from memory (rather than copy and paste).
Exactly the reason why people remember their mobile phone number. Except that you replace "opportunity to exchange some BTC" with "opportunity to get the pretty girl". Wink

Quote
if it gets accepted by "normal" people everything is fine. a solution only for btc-enthusiasts seems unnecessary.
We'll see, accepted or not this will be implemented. We'll see if people use it.
My point is that people remember the 10 digit of their phone number, and there is a reason for it. "Being Geek" is not the reason why they are doing it.

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
hhanh00
Sr. Member
****
Offline Offline

Activity: 467
Merit: 267


View Profile
March 09, 2015, 04:18:33 AM
Last edit: March 09, 2015, 04:32:39 AM by hhanh00
 #152

Encode (blockheight, txIndex, txoIndex, pubScript) into a list of numbers between 0 and 2047.

Preconditions: txoIndex < 4

The result is the concatenation of three sub lists that encodes each part
## blockHeight
- The blockheight split into blocks of 10 bits, least significant block first.
- All blocks except the last one has its most significant bit (11th bit) set to 1

## txoIndex and checksum
- The DSHA-256 is calculated over the pubScript
- The first 2 bytes + 4 Least significant bits of the 3rd byte are kept, giving the 20-bit checksum
- The txoIndex is appended
- The 22 bit result is split into two groups of 11 bits

## txIndex
- The txIndex is split into groups of 11 bits, least significant byte first

# Transform the list into words

Notes:
- There is no version bit. The context should make the version clear. Alternatively, when
the encoding needs to change, a different list of words can be substituted.
- No limit on the blockheight
- For the first 2^20 blocks and txIndex below 2^11, the scheme results in 5 words. It is independent
from the actual number of transactions in the block
- The encoding is essentially a combination of a variable length integer with continuation bit, a fixed record and a variable
length integer.
- The checksum only covers the pubscript. The goal of the method is to locate a particular address or more generally a
particular pubscript. The blockHeight, txIndex and txoIndex provide the 'coordinates' of the pubscript and the checksum
makes sure that it is the right one. If there is a block reorg, the decoding will retrieve a different pubscript and the verification
will fail.
- The encoding is a pure function. It only takes the location and the content of the data. No need for other information from the blockchain.
- The result is not further encrypted. It is a public scheme.

I'm a newb in Haskell so this is probably not idiomatic:
Code:
import Debug.Trace
import Data.Bits
import Control.Applicative
import Control.Monad
import qualified Data.ByteString as B
import qualified Data.ByteString.Lazy as LB
import qualified Crypto.Hash.SHA256 as SHA2
import qualified Data.Binary.Get as G

dsha = SHA2.hash . SHA2.hash
setContinuationBit :: Int -> [Int] -> [Int]
setContinuationBit position (x:xs) = (x .|. (shift 1 position)):xs

splitIntoWords :: Int -> [Int] -> Int -> Bool -> [Int]
splitIntoWords 0 result size cont =
    reverse (if cont then (setContinuationBit size result) else result)
splitIntoWords i result size cont =
    let mask = (shift 1 size)-1
    in splitIntoWords (shift i (-size)) ((i .&. mask):result) size cont
   
encodeTx :: Int -> Int -> Int -> B.ByteString -> [Int] 
encodeTx blockHeight txIndex txoIndex pubScript =
    let blockHeightEncoded = splitIntoWords blockHeight [] 10 True
           
        txoIndexEncoded =
            let shaDecoder = do
                    bs <- (G.getByteString 4)
                    shaChecksum <- liftM fromIntegral G.getWord32le
                    return shaChecksum
                checksum = G.runGet shaDecoder (LB.fromChunks [dsha pubScript])
                checksumAndTxoIndex = (shift checksum 2) .|. txoIndex
                checksumWords = splitIntoWords checksumAndTxoIndex [] 11 False
            in take 2 checksumWords
       
        txIndexEncoded = splitIntoWords txIndex [] 11 False
    in blockHeightEncoded ++ txoIndexEncoded ++ txIndexEncoded
   
main =
    print (encodeTx 346694 500 2 (B.pack [1, 2, 40, 21]))

jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
March 09, 2015, 05:05:28 AM
 #153


Notes:
- There is no version bit. The context should make the version clear. Alternatively, when
the encoding needs to change, a different list of words can be substituted.


It is an impossible task to find 2048 completely different and easily memorable words

- No limit on the blockheight

I think 8 million blocks is already "no limit", and it's likely to have a hardfork that will obsolete any current address scheme

- For the first 2^20 blocks and txIndex below 2^11, the scheme results in 5 words. It is independent
from the actual number of transactions in the block

It is the only benefit but the cost is to strictly limit the use of such address and ignore many sophisticated use of the blockchain.

- The checksum only covers the pubscript. The goal of the method is to locate a particular address or more generally a
particular pubscript. The blockHeight, txIndex and txoIndex provide the 'coordinates' of the pubscript and the checksum
makes sure that it is the right one. If there is a block reorg, the decoding will retrieve a different pubscript and the verification
will fail.

Please refer to gmaxwell's criticism in the first page. Without covering the blockheight in the checksum, a miner could mine a "vanity address" without any cost. If the incentive is big enough (e.g. the address is "best adult adult adult web"), miners will fill the block with garbage and orphan other people's block in order to grab it.

Inclusion of txIndex and txoIndex in checksum is for different use case. In some application, e.g. smart-property, the position of the output could be as important as the scriptPubKey.

- The encoding is a pure function. It only takes the location and the content of the data. No need for other information from the blockchain.
- The result is not further encrypted. It is a public scheme.

Any addresses of this kind are meaningless without information from the blockchain. And the complexity added is completely transparent to end users. No one is expected to encode or decode it by hand.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
hhanh00
Sr. Member
****
Offline Offline

Activity: 467
Merit: 267


View Profile
March 09, 2015, 06:37:11 AM
 #154

Quote
It is an impossible task to find 2048 completely different and easily memorable words
I beg to differ. Our vocabulary exceeds 10 000 words. Besides these words are not so memorable (at least for me) and I'm not sure they were meant to be.

Quote
I think 8 million blocks is already "no limit", and it's likely to have a hardfork that will obsolete any current address scheme
It's quite big enough. But omitting the version bit simplifies the encoding.

Quote
It is the only benefit but the cost is to strictly limit the use of such address and ignore many sophisticated use of the blockchain.
We have different use case in mind.

Quote
Please refer to gmaxwell's criticism in the first page. Without covering the blockheight in the checksum, a miner could mine a "vanity address" without any cost. If the incentive is big enough (e.g. the address is "best adult adult adult web"), miners will fill the block with garbage and orphan other people's block in order to grab it.
An address points to a very specific location and one would have to be quite clever to produce a correct spot. Then he would have to mine the correct script and work with the miner to get the spot. I think he deserves that spot.

Quote
Any addresses of this kind are meaningless without information from the blockchain. And the complexity added is completely transparent to end users. No one is expected to encode or decode it by hand.
From a coding point of view, having fewer dependencies is good.

Eventually, people will vote for a BIP with their wallet ... app. It seems that we reach a point where we understand the pros/cons of each scheme. So I wish you good luck with your BIP and hope that it will be a big success.


Nicolas Dorier (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 662


View Profile
March 09, 2015, 01:28:29 PM
 #155

Quote
Eventually, people will vote for a BIP with their wallet ... app. It seems that we reach a point where we understand the pros/cons of each scheme. So I wish you good luck with your BIP and hope that it will be a big success.
hhanh00, I don't really understand the pros of your scheme right now.
Except the block limit. It does not seems to be more compact. Maybe more easy to implement, but with good test vectors we should have no problem's with jl2012's scheme.
Quote
There is no version bit. The context should make the version clear.
I agree. And if there is another version of the scheme the checksum will be able to detect if it's a valid address mnemonic or not anyway.
Quote
The encoding is a pure function. It only takes the location and the content of the data. No need for other information from the blockchain.
I don't understand this argument. Can you details ?
Quote
Eventually, people will vote for a BIP with their wallet ... app.
This is true, but I will only implement one of those in NBitcoin. If the market choose the other scheme I will adapt, but the wallet app most of the time rely on what their Bitcoin framework offers.
I just want to find the most compact way of doing it.
Quote
The result is not further encrypted. It is a public scheme
Why does the encryption is a problem ?
The way jl2012 does it provide an uniform distribution on the probability of each word of occuring, which is a nice thing to have.

hhanh00, Your way of doing does not seems more compact but is also less flexible, can you provide a clear pros/cons list ? because except ease of implementation and block limit, I don't see anything.

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
March 09, 2015, 02:07:36 PM
 #156

Quote
Eventually, people will vote for a BIP with their wallet ... app. It seems that we reach a point where we understand the pros/cons of each scheme. So I wish you good luck with your BIP and hope that it will be a big success.
hhanh00, I don't really understand the pros of your scheme right now.
Except the block limit. It does not seems to be more compact. Maybe more easy to implement, but with good test vectors we should have no problem's with jl2012's scheme.
Quote
There is no version bit. The context should make the version clear.
I agree. And if there is another version of the scheme the checksum will be able to detect if it's a valid address mnemonic or not anyway.
Quote
The encoding is a pure function. It only takes the location and the content of the data. No need for other information from the blockchain.
I don't understand this argument. Can you details ?
Quote
Eventually, people will vote for a BIP with their wallet ... app.
This is true, but I will only implement one of those in NBitcoin. If the market choose the other scheme I will adapt, but the wallet app most of the time rely on what their Bitcoin framework offers.
I just want to find the most compact way of doing it.
Quote
The result is not further encrypted. It is a public scheme
Why does the encryption is a problem ?
The way jl2012 does it provide an uniform distribution on the probability of each word of occuring, which is a nice thing to have.

hhanh00, Your way of doing does not seems more compact but is also less flexible, can you provide a clear pros/cons list ? because except ease of implementation and block limit, I don't see anything.

hhanh00's scheme guarantees 5-words address for the first 4 outputs in the first 2048 tx in any block, regardless the number of tx in the block
my scheme guarantees 5-words address for the first 4 outputs in any block with =< 2048tx (similar but a bit less efficient)

However, the cost of the extra efficiency is:

hhanh00's scheme works only with the first 4 outputs in any tx
my scheme works with any output in any tx

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

Since the address is only 44-77bits, dropping the version bit may lead to unintentional birthday attack between the old and new schemes: http://en.wikipedia.org/wiki/Birthday_attack

i.e. An address is valid in both schemes but interpreted differently

Any mathematician to explain?

In that case, you need something like  oldscheme://web-satoshi-away-load  and newscheme://web-satoshi-away-load  , essentially adding 1 more bit to the address externally

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Nicolas Dorier (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 662


View Profile
March 09, 2015, 02:19:17 PM
 #157

Quote
my scheme guarantees 5-words address for the first 4 outputs in any block with =< 2048tx (similar but a bit less efficient)
Your scheme save bits if the address is on the first output. (it can be encoded in 0 bits)
If we strip out the version bit, then we earn a third bit.

So it would push the limit to =< 16384. Alternatively, I think we can squeeze the checksum a bit.
Even if Bitcoin becomes an overnight success, one can publish an output multiple time on the blockchain to increase the odd to be in a block with few transactions.

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
March 09, 2015, 02:58:15 PM
 #158

Quote
my scheme guarantees 5-words address for the first 4 outputs in any block with =< 2048tx (similar but a bit less efficient)
Your scheme save bits if the address is on the first output. (it can be encoded in 0 bits)
If we strip out the version bit, then we earn a third bit.

So it would push the limit to =< 16384. Alternatively, I think we can squeeze the checksum a bit.
Even if Bitcoin becomes an overnight success, one can publish an output multiple time on the blockchain to increase the odd to be in a block with few transactions.

Yes, it guarantees 5-words address for the first output in the first 8192 txs in any block, regardless the total number of tx in the block.
-----------------
The version bit may be removed but be prepared to externalize it. It could also help implementing the scheme to alt-coins. We may have something like:

bitcoin:load-road-road-load-road
litecoin:road-load-load-road-load

and in the future, after a significant hardfork, we have

bitcoin2:load-road-road-load-road, which will be interpreted differently

Not sure if this is a good way to go


Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Nicolas Dorier (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 662


View Profile
March 09, 2015, 04:22:50 PM
 #159

Quote
bitcoin:load-road-road-load-road
litecoin:road-load-load-road-load

and in the future, after a significant hardfork, we have

bitcoin2:load-road-road-load-road, which will be interpreted differently

Not sure if this is a good way to go

I don't think it is useful at this point to format the mnemonic into an url.
If there is an url, the user is mostly clicking on that or put it into QR code, and in both case would not need a mnemonic.

Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1086


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 09, 2015, 04:25:11 PM
 #160

I thought you guys were headed towards a consensus - but now we have two ideas?

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Pages: « 1 2 3 4 5 6 7 [8] 9 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!