Nicolas Dorier (OP)
|
|
February 27, 2015, 03:23:40 AM |
|
I found a way to fix all the problems you pointed out. Having a SPV proofI will encode a location in the blockchain in the following way : [Height]-[PathToLeaf]-[TxOut index] (I'll call such information a "blockchain address") [PathToLeaf] will be a bit array describing how to go from the merkle root down to the leaf representing the transaction. (1 for go right, 0 for go left) This has the nice effect to be shorter than the [Tx Index] I thought about, but also to fit in a classical Partial Merkel Tree. (Log(N;2) bit on the transaction count of the block) Fixing Address ReuseIf the blockchain address references a TxOut that is not OP_RETURN, then it it referencing the ScriptPubKey. (do not fix address reuse) If the blockchain address references a TxOut that is a OP_RETURN, then, it checks if the content is a Bitcoin Payment URL. (fix the address reuse problem, because if it is BIP70, a new address will be evaluated each time) Preventing user error caused by similar wordsWe can append a checksum at the end of the the "blockchain address" before encoding it in a "brain address" such as: Brain Address = ([height]-[PathToLeaf]-[TxOut index]) + Hash([height]-[PathToLeaf]-[TxOut index])[0] Now if the user mistake between two words, there will be no risk of sending funds to the wrong place. Result: All blockchain reference and address could be represented in 3 or 4 easy to remember words, only with the blockchain. This fix all shortcoming of firstbits : - it remove any need of trust relationship with a "brain address" web service.
- payment destinations are memorizable
- A SPV client only need a partial merkle tree for checking the result
- No fixed address
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
|
|
|
Make sure you back up your wallet regularly! Unlike a bank account, nobody can help you if you lose access to your BTC.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
Kazimir
Legendary
Offline
Activity: 1176
Merit: 1003
|
|
February 27, 2015, 09:39:46 AM |
|
Why would you want to remember a Bitcoin address at all? That's a mistake. 1. We got software to do that for us. 2. You should avoid reusing addresses as much as possible. Let me quote myself from another thread: It would have been better if the addresses were 1577 characters long, and contained random gibberish characters.
That way, we'd be sure that NOBODY would be as stupid to manually type an address, or even try to remember it.
Remember folks, ALWAYS use copy paste / share / QR / links!
|
|
|
|
Nicolas Dorier (OP)
|
|
February 27, 2015, 11:24:46 AM |
|
Why would you want to remember a Bitcoin address at all? That's a mistake. 1. We got software to do that for us. 2. You should avoid reusing addresses as much as possible. Let me quote myself from another thread: It would have been better if the addresses were 1577 characters long, and contained random gibberish characters.
That way, we'd be sure that NOBODY would be as stupid to manually type an address, or even try to remember it.
Remember folks, ALWAYS use copy paste / share / QR / links!
As I said, I fixed the address reuse problem, so it should not be a concern. The reason why I want to do that is kinda the same reason why most people memorize their own mobile phone number. You can't have forgotten it at home when someone ask for it.
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
btchris
|
|
February 27, 2015, 05:35:48 PM |
|
If the blockchain address references a TxOut that is a OP_RETURN, then, it checks if the content is a Bitcoin Payment URL. (fix the address reuse problem, because if it is BIP70, a new address will be evaluated each time)
It sounds like your scheme (in the BIP70 case) is simply a URL shortener, except that in some cases it will end up being more of a URL lengthener.... remembering a few random English words seems harder to me than simply remembering a domain name that one creates for that purpose. It would be useful if services provided the option for a user to provide an extended pubkey. For example since people love change addresses a forum like this could have a field on the profile where the user provides an extended pubkey. The site would not display the address publicly but would compute the next address from the extended pubkey and display that. When a transaction is detected it would increment and display the next address.
At least one online wallet does this, for example if you'd like to send me a tip, visit here: https://greenaddress.it/pay/GAMiQ3yzZFD6djdqpYo4YGdRHrMot/ (they have only my xpub, assuming of course that you trust their client software isn't malware).
|
|
|
|
Nicolas Dorier (OP)
|
|
February 27, 2015, 08:14:30 PM |
|
If the blockchain address references a TxOut that is a OP_RETURN, then, it checks if the content is a Bitcoin Payment URL. (fix the address reuse problem, because if it is BIP70, a new address will be evaluated each time)
It sounds like your scheme (in the BIP70 case) is simply a URL shortener, except that in some cases it will end up being more of a URL lengthener.... remembering a few random English words seems harder to me than simply remembering a domain name that one creates for that purpose. Except you can't expect average Joe to manage his own domain name, and host his own payment server. Average Joe can create an account on a third party payment server though. But such server : either provide an url that can't be remembered and easily spelled. ( http://payment.com/u/dzopUDZiziK) Either use the user's name ( http://payment.com/u/toto), but in such case, you can easily get misspell the user name or domain, resulting to money sent to someone else. My scheme do works whatever how a payment url is created.
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
btchris
|
|
February 27, 2015, 08:47:59 PM |
|
Except you can't expect average Joe to manage his own domain name, and host his own payment server. Average Joe can create an account on a third party payment server though.
That's kind of the point though. If Joe can't run his own payment server (and wants to avoid address re-use), then he's stuck with a centralized solution anyways. And if he's stuck being centralized, there doesn't seem to be much reason to use the blockchain to look up some account ID if the centralized provider he's chosen can do it instead. But such server : either provide an url that can't be remembered and easily spelled. ( http://payment.com/u/dzopUDZiziK) Either use the user's name ( http://payment.com/u/toto), but in such case, you can easily get misspell the user name or domain, resulting to money sent to someone else. If the payment processor implements an easy URL scheme with a short checksum, than that's great. It doesn't require encoding anything on the blockchain, though. Maybe there's more merit to the static-address solution you've described. I'm skeptical that it offers much improvement over firstbits, but I could be wrong.
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
February 28, 2015, 06:28:12 PM |
|
FirstBits didn't require centralized trust. Indeed, I messed up with another service. By the way "1kk5k" is hardly memorizable, using words should be better. Would you memorize your bank account number? I won't. Why should I memorize by bitcoin address?
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
najzenmajsen
|
|
February 28, 2015, 08:14:56 PM |
|
Why would you want to remember a Bitcoin address at all? That's a mistake. 1. We got software to do that for us. 2. You should avoid reusing addresses as much as possible. Let me quote myself from another thread: It would have been better if the addresses were 1577 characters long, and contained random gibberish characters.
That way, we'd be sure that NOBODY would be as stupid to manually type an address, or even try to remember it.
Remember folks, ALWAYS use copy paste / share / QR / links!
hey , would you please tell me why we should avoid reusing adresses ? cause i dont see a reason to do that. please aware me : >
|
|
|
|
btchris
|
|
February 28, 2015, 08:39:15 PM |
|
Would you memorize your bank account number? I won't.
Why should I memorize by bitcoin address?
I don't think that's a fair analogy. (I think) OP's desire was to make it easy to create or reference a receive address in informal situations without carrying anything with you (e.g. splitting a bill with a friend). Traditional transaction mechanisms do that just fine today (cash: don't need to remember anything; checks: just need to remember your own name; centralized e-money (e.g. PayPal), just need to remember your email address/account ID). I think such a mechanism for Bitcoin would be great, but I'm skeptical that any such mechanism would meet a reasonable set of minimum requirements. My own set of requirements would include: - Easy to remember
- Easy to set up/maintain
- Decentralized
- No address re-use
If you can't achieve all of the above, than you need to prioritize. I'd nix either the first or the second, and that's what we already have today (base58check or BIP70). I think nixing either of the other two would be a worse idea, but that's subjective.
|
|
|
|
laurentmt
|
|
February 28, 2015, 09:27:11 PM |
|
I found a way to fix all the problems you pointed out.
Hi Nicolas, Really interesting idea but I fear you still have to cope with blockchain pruning if you plan to store this data in the bitcoin blockchain. Why not rely on a bip70 uri stored in namecoin blockchain ? Out of topic: congrats for your book. amazing work !
|
|
|
|
Nicolas Dorier (OP)
|
|
February 28, 2015, 11:01:39 PM |
|
FirstBits didn't require centralized trust. Indeed, I messed up with another service. By the way "1kk5k" is hardly memorizable, using words should be better. Would you memorize your bank account number? I won't. Why should I memorize by bitcoin address? Do you memorize you mobile phone number ? I do, and my friends do. hey , would you please tell me why we should avoid reusing adresses ? cause i dont see a reason to do that. please aware me Quoting myself (I thought about it after people on this thread told me it would be a significant problem, but not initially) Fixing Address Reuse If the blockchain address references a TxOut that is not OP_RETURN, then it it referencing the ScriptPubKey. (do not fix address reuse) If the blockchain address references a TxOut that is a OP_RETURN, then, it checks if the content is a Bitcoin Payment URL. (fix the address reuse problem, because if it is BIP70, a new address will be evaluated each time) I think such a mechanism for Bitcoin would be great, but I'm skeptical that any such mechanism would meet a reasonable set of minimum requirements. My own set of requirements would include: Easy to remember Easy to set up/maintain Decentralized No address re-use It does everything above, since the proof is a simple partial merkle tree (no trust relationship), that can reference a BIP70 address, as opposed to a fixed address, all data is stored on the blockchain. I found a way to fix all the problems you pointed out. Having a SPV proofI will encode a location in the blockchain in the following way : [Height]-[PathToLeaf]-[TxOut index] (I'll call such information a "blockchain address") [PathToLeaf] will be a bit array describing how to go from the merkle root down to the leaf representing the transaction. (1 for go right, 0 for go left) This has the nice effect to be shorter than the [Tx Index] I thought about, but also to fit in a classical Partial Merkel Tree. (Log(N;2) bit on the transaction count of the block) Fixing Address ReuseIf the blockchain address references a TxOut that is not OP_RETURN, then it it referencing the ScriptPubKey. (do not fix address reuse) If the blockchain address references a TxOut that is a OP_RETURN, then, it checks if the content is a Bitcoin Payment URL. (fix the address reuse problem, because if it is BIP70, a new address will be evaluated each time) Preventing user error caused by similar wordsWe can append a checksum at the end of the the "blockchain address" before encoding it in a "brain address" such as: Brain Address = ([height]-[PathToLeaf]-[TxOut index]) + Hash([height]-[PathToLeaf]-[TxOut index])[0] Now if the user mistake between two words, there will be no risk of sending funds to the wrong place. Result: All blockchain reference and address could be represented in 3 or 4 easy to remember words, only with the blockchain. This fix all shortcoming of firstbits : - it remove any need of trust relationship with a "brain address" web service.
- payment destinations are memorizable
- A SPV client only need a partial merkle tree for checking the result
- No fixed address
Hi Nicolas, Really interesting idea but I fear you still have to cope with blockchain pruning if you plan to store this data in the bitcoin blockchain. Why not rely on a bip70 uri stored in namecoin blockchain ? Out of topic: congrats for your book. amazing work ! Thanks laurent, the second part will release beginning of march. I don't want to rely on namecoin and another blockchain since the bitcoin network can already do that easily. BIP70 is fine, but as I said, you can't ask Joe to register a domain name and hosting its server. If Joe use a third party service for that, then, most of the time the url can't be memorized (hard to remember ids). If it can be memorized, the longer the address, the higher the chances to send money to someone else by mistake. That's a lot of if, that in any case my scheme would solve. My scheme would have a checksum embedded and can fit any payment destination (BIP70 or fixed address) in 4 easy to remember, and hard to mix up words.
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
btchris
|
|
February 28, 2015, 11:35:32 PM |
|
I think such a mechanism for Bitcoin would be great, but I'm skeptical that any such mechanism would meet a reasonable set of minimum requirements. My own set of requirements would include: Easy to remember Easy to set up/maintain Decentralized No address re-use It does everything above, since the proof is a simple partial merkle tree (no trust relationship), that can reference a BIP70 address, as opposed to a fixed address, all data is stored on the blockchain. I thought we agreed that it didn't meet both "Easy to set up/maintain" and "No address re-use" at the same time, given that BIP70 isn't easy to run on your own (or it fails "Decentralized" if you use a 3rd-party processor which implements BIP70)?
|
|
|
|
R2D221
|
|
March 01, 2015, 03:19:45 AM |
|
Nobody has discussed that this proposal is anglocentric. I speak Spanish, and it's as hard for me to learn “car yellow what” than “1hshbx”.
|
An economy based on endless growth is unsustainable.
|
|
|
hhanh00
|
|
March 01, 2015, 06:56:40 AM Last edit: March 01, 2015, 12:30:24 PM by hhanh00 |
|
PathToLeaf will be a bit array describing how to go from the merkle root down to the leaf representing the transaction. (1 for go right, 0 for go left) This has the nice effect to be shorter than the [Tx Index] I thought about, but also to fit in a classical Partial Merkel Tree. (Log(N;2) bit on the transaction count of the block) How is PathToLeaf different that the txIndex? It looks to me that if you write the txIndex in binary, you have the same result. If the blockchain address references a TxOut that is not OP_RETURN, then it it referencing the ScriptPubKey. (do not fix address reuse) If the blockchain address references a TxOut that is a OP_RETURN, then, it checks if the content is a Bitcoin Payment URL. (fix the address reuse problem, because if it is BIP70, a new address will be evaluated each time) It fixes the address reuse if and only if the user is willing to set up a payment server. But later you say that most people wouldn't go through the trouble of doing so. Preventing user error caused by similar words We can append a checksum at the end of the the "blockchain address" before encoding it in a "brain address" such as: Brain Address = ([height]-[PathToLeaf]-[TxOut index]) + Hash([height]-[PathToLeaf]-[TxOut index])[0] Now if the user mistake between two words, there will be no risk of sending funds to the wrong place. It works with a carefully crafted dictionary. What would you use? Would you be able to provide one for different languages? The checksum detects errors but doesn't correct them. Your friend would not be able to pay you. Result: All blockchain reference and address could be represented in 3 or easy to remember words, only with the blockchain. But it prevents pruning. Eventually, people will not have your tx if it's buried deep down and they will rely on an online service. In any case, I'm not sure there is a need for this. If it's a large amount, I would prefer to give a QR code or a payment URL (if I'm a business). For a small amount, I would tell my friend that I will email him the address later or I'd set up a gmail account pay-hhanh00@gmail.com with an autoreply that gives a payment address.
|
|
|
|
|
Nicolas Dorier (OP)
|
|
March 01, 2015, 02:53:06 PM Last edit: March 01, 2015, 03:12:55 PM by Nicolas Dorier |
|
I thought we agreed that it didn't meet both "Easy to set up/maintain" and "No address re-use" at the same time, given that BIP70 isn't easy to run on your own (or it fails "Decentralized" if you use a 3rd-party processor which implements BIP70)? It fixes the address reuse if and only if the user is willing to set up a payment server. But later you say that most people wouldn't go through the trouble of doing so. I agree that there is still a trust relationship between the BIP70 provider and the user. However there is no trust relationship between a "Brain address" provider and its user. (contrary to firstbits) What we can't do with my scheme is having both : No address reuse + No trust relationship with BIP70 provider, you have to pick one of those. It can be solved theorically by publishing a Stealth Address in the OP_RETURN instead of a bitcoin payment url. But I don't think Stealth Addresses are wild spread enough for now, and is a pain because of OP_RETURN limits. How is PathToLeaf different that the txIndex? It looks to me that if you write the txIndex in binary, you have the same result. You have indeed the same result, the difference is that a PathToLeaf is an information that can be checked in a Partial Merkle Tree (SPV), while TxIndex is not. The difference is in the size of the proof. In the first case, the "brain address provider" would need to send you either the whole block as the specified Height to prove he is not lying, or the ordered list of all Transaction Ids in the block. (this latter proof is compact enough but can't be fetched directly on the bitcoin network) In the second case, the "brain address provider" just need to give you the Transaction + Block Header + Partial Merkle Tree to it. (such information can be retrieved directly by connecting to the bitcoin network, on low capacity/bandwidth devices) It works with a carefully crafted dictionary. What would you use? Would you be able to provide one for different languages? The checksum detects errors but doesn't correct them. Your friend would not be able to pay you. Nobody has discussed that this proposal is anglocentric. I speak Spanish, and it's as hard for me to learn “car yellow what” than “1hshbx”. I would use BIP39 dictionary. https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.mdCurrently supported are English,Japanese,Spanish,Chinese (Simplified),Chinese (Traditional) and more will be provided by the community in the future. But it prevents pruning. Eventually, people will not have your tx if it's buried deep down and they will rely on an online service. You can rely on an untrusted "brain address provider" thanks to the simplicity of the proof, people don't need the full blockchain. In any case, I'm not sure there is a need for this. Maybe, the best way to know is to try, and I will. My point is that you don't memorize wire transfer account number because you can't, not because you don't have the need. This is why people still remember their phone number, it can fit in their brain. A BIP70 most likely do not and is prone to lookalike attacks. I believe that if people have a way to easily memorize a payment destination, they will use it. I have a subtle exercise for you, advocating about remembering/sharing a payment url : What is the difference between " http://payment.com/u/tata" and " http://payment.com/u/tata" ? (you can try comparing these two addresses in your favorite programming language, they are not the same)
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
btchris
|
|
March 01, 2015, 03:53:49 PM |
|
(Slightly OT) FYI BIP39 wordlists aren't guaranteed to use unique words wrt each other; in particular the two Chinese word lists share over 50% of their words so you'd probably need to choose one over the other (or neither).
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1097
|
|
March 01, 2015, 05:42:02 PM |
|
I found a way to fix all the problems you pointed out.
Having a SPV proof I will encode a location in the blockchain in the following way : [Height]-[PathToLeaf]-[TxOut index] (I'll call such information a "blockchain address")
You have not fixed the following problems: 1. blockchain reorg 2. Miners may try to fill up a block with garbage for a vanity address To fix the reorg problem you have to include blockhash and/or tx-hash somewhere in your formula. This is tricky because that would lengthen the address To fix the vanity address problem miner shouldn't be able to determine the address before a block is found. Again, this is avoided if the blockhash is part of the formula ------------------------ I'd like to propose the following method for referring any ScriptPubKey on the blockchain. I don't care how people interpret the information in the ScriptPubKey: Version: 1 bit (always 0) Height: 20 bits (up to block 1048576, enough for 13 years) txIndex: 19 bits (up to 524288 tx/block, won't happen until the blocksize is >110MB) TxOut index: 8 bits (up to 256 outputs/tx) Checksum: 29 bits (slightly weaker than 32 bits in a standard bitcoin address) Total: 77 bits, requiring 7 words to encode All components are zero-padded. Anything beyond block 1048576 / txIndex 524288 / TxOut index 256 are invalid. Checksum is the first 29 bits of SHA256(Blockhash-ScriptPubKey) The 48-bits (Version-Height-txIndex-TxOut index) is split into 6 fragments of 8-bits The 29-bits Checksum is split into 5 fragments of 5-bits and 1 fragment of 4-bits Fragments are concatenated alternatively, so miners are not able to mine a vanity address without giving up a successful block hash. To resolve the address, an SPV node has to obtain the ScriptPubKey with Height-txIndex-TxOut index, and verify the Checksum with Blockhash-ScriptPubKey Reducing to 6 words is possible but it reduces the checksum security and future compatibility Version: 1 bit (always 0) Height: 20 bits (reducing to 19 bits will make it overflows in less than 4 years) txIndex: 16 bits (up to 65536 tx/block, won't happen until the blocksize is >13MB) TxOut index: 5 bits (up to 32 outputs/tx) Checksum: 24 bits (Not sure if this is enough) Total: 66 bits Or 5 words: Version: 1 bit (always 0) Height: 20 bits txIndex: 13 bits (up to 8192 tx/block, won't happen until the blocksize is >1.5MB) TxOut index: 4 bits (up to 16 outputs/tx) Checksum: 17 bits (This could be risky) Total: 55 bits 8 words would be good enough for foreseeable future. It's still much better than encoding an 160-bits address with 15 words: Version: 1 bit (always 0) Height: 22 bits (enough for >70 years) txIndex: 25 bits (enough for 6.8GB block) TxOut index: 11 bits (up to 2048 outputs/tx) Checksum: 29 bits Total: 88 bits
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
Nicolas Dorier (OP)
|
|
March 01, 2015, 07:34:10 PM |
|
1. blockchain reorg This is the problem of the wallet implementation. Whether they are using my spec or not, they need to manage that correctly (needed for checking a Partial Merkel Tree), this is orthogonal to my spec. Do you refer to the fact that one "brain address" might point to an invalid TxOut after a reorg ? One way to mitigate that is to ask for 101 confirmations. (coinbase maturity) However, the fact that some services will not want waiting so much time, even if my spec ask for it, might be troublesome. I don't have a better solution though. 2. Miners may try to fill up a block with garbage for a vanity address Why would they do that ? there is nothing to win by doing that. I will not use your encoding technique. The reason is that there is no reason to choose the number of words in a "brain address". As opposed to a private key, the fewer the better. The best way to encode a "Brain Address" is to use the VarInt encoding that all bitcoin wallet already implement. (or the less supported CompactVarInt internal to bitcoin core) Also, encoding the TxIndex is inferior to encoding the PathToLeaf, for 2 reasons : it takes more space, and more than a simple Partial Merkle Tree would be required as proof. (whose proof checks are already implemented in all SPV wallets) Code reuse would be maximized, code error minimized, so adoption by wallet providers should be better. Moreover, each words represents 11 bits of information. If we need 23 bit for encoding an address, then we have 10 bit that serve for nothing. I propose to fit the checksum inside. The size of the checksum in bit would be something like Max(5, UnusedBitCount). This should represent all current payment destination on 3 or 4 words. And it will goes up very very slowly.
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
hhanh00
|
|
March 02, 2015, 12:47:56 AM |
|
I'm completely confused by what you are saying now. The txindex = path. How can one be better than the other unless you are adding data. I guess we will see once you implement it. The worst that can happen is people losing their coins
|
|
|
|
|