|
You shouldn't worry about potential corruption because you should backup your private key properly
|
|
|
|
This is the reason that setting the passphrase forces a shutdown. Bitcoin core completely rewrites the wallet and deletes the old file.
Especially with modern disks and file systems once data has _ever_ hit the disk you cannot be confident that it has been deleted-- e.g. _no_ SSD will do rewrite-in-place.
This is less of a big deal than you might expect because the keypool is all set to 'used' prior to encryption, so any address you retrieve from the wallet after enabling encryption will be born encrypted and will have never been on the disk unencrypted.
Why doesn't the bitcoind fill the old wallet with zeros before deleting it? You'd be safe for everything except fancy forensic magnetism leaking which is useless after some time using the disk. highlight for you |
|
|
|
|
我相信在任何一個正常國家, 未經特別批准自稱銀行都是犯法的
|
|
|
|
|
In terms of mining profitability, reward halving and price collapsing by 50% have the same effect, except that the first one is planned and highly predictable and the latter one is not.
|
|
|
|
I know that many will not like this  I saw that if I sign a file with a private key, that the hex will take 65 bytes (that are less than 80 bytes, so it's ok) By spreading signs on the Blockchain, than a service will be able to find how many data/files are signed by someone, by knowing his own Bitcoin address. But it will not be able to know which files are signed by him. If instead someone puts the hash (sha256 is 32 bytes) of his files on the Blockchain, then everyone (or a service) will be able to see that someone else has already claimed these files, but it will not be possible to know who is the owner. Putting both sign + file_hash (65 + 32 = 97) in the OP_RETURN will give the possibility to a service, or even a dedicated full client, connected with a full node, to know everything. It will know if a file is already claimed and who claimed it. Just by adding these 17 bytes that we will get this great function  Anyway, do you know any cheaper way (with less bytes) to get the same result? Is it possible to achieve the same with only 80 bytes? I know that the easier way is just by making two chained transaction, but it would be cool to still be able to do with just one. Just take the first 15 bytes of the hash. To avoid collision, 120bits is already overkill |
|
|
|
1. Do we want the ability to encode all outputs in the blockchain, or just some of it (say, only the first 4 outputs in all txs)? hhanh00's scheme is easier to implement as it only encodes the first 4 outputs in a tx. My scheme is more complex and the length of all components are variable.
I guess the "target audience" is what matters (for me 4 outputs would be fine as I would be using it for "cold storage" which would have generally only 1 output anyway). My scheme allows users to choose. If you want the shortest possible address, always put your interested scriptPubKey as the first output. If you have some special reasons (e.g. when using smart property which the order of outputs is material), you can use my scheme to refer to any outputs on the blockchain. 2. hhanh00's address is shorter than mine in some case, while the opposite in some other case.
I think 5 "words" is fine (whichever approach). Basically, 5 words is guaranteed in most cases for both proposal if the 1MB block space is not increased. 3. How many bits of checksum is needed? I proposed 20bits so the error tolerance is about 1 in a million. Should we use more? Could we squeeze a few bits for other purpose? (Satoshi used 32 bits in standard bitcoin address.)
As many as possible without adding an extra word. You are begging the question: in my scheme, the only way to ensure no extra word is to use 0-bit checksum. So go back to the question, how many bits of checksum is needed? 5. Do we want miner to have the ability to mine a vanity address? My scheme disallows it in response to gmaxwell's comments (see first page). The other scheme allows miners to mine vanity address.
I am not quite sure of the implications of this - but it would be better to probably not allow it. The implication is a miner may try to fill up a block with garbage in order to grab a vanity address. It also offers extra incentive to orphan other people's block. |
|
|
|
People are always free to propose different ideas. I just want more people to comment and criticize.
To be honest it is now confusing exactly what is on offer (it got rather technical and I didn't have enough time to delve into it). Perhaps a simple summary of the two options could be provided? There are many dimensions: 1. Do we want the ability to encode all outputs in the blockchain, or just some of it (say, only the first 4 outputs in all txs)? hhanh00's scheme is easier to implement as it only encodes the first 4 outputs in a tx. My scheme is more complex and the length of all components are variable. 2. hhanh00's address is shorter than mine in some case, while the opposite in some other case. 3. How many bits of checksum is needed? I proposed 20bits so the error tolerance is about 1 in a million. Should we use more? Could we squeeze a few bits for other purpose? (Satoshi used 32 bits in standard bitcoin address.) 4. Do we need a version bit (like in standard bitcoin address)? It will occupy 1 bit (which could be otherwise used for other purpose. In order to keep the address short, every bit is very valuable) but it makes potential future upgrade easier. Otherwise, future upgrade will need to use 2048 completely different words, or people have to denote the version of the address externally (e.g. using a URL like header) 5. Do we want miner to have the ability to mine a vanity address? My scheme disallows it in response to gmaxwell's comments (see first page). The other scheme allows miners to mine vanity address. 6. Do we want the addresses look like random (i.e. outputs/txs close to each other will have statistically unrelated addresses) or not? |
|
|
|
I thought you guys were headed towards a consensus - but now we have two ideas?
People are always free to propose different ideas. I just want more people to comment and criticize. |
|
|
|
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. It is not about URL. If there will be any update with this scheme, without a version bit, future users has to tell people whether this is a version 1 or version 2 address. Otherwise, birthday collision is very likely: an address (with or without checksum) being perfectly legal in different schemes |
|
|
|
Using P2SH multisig is there a way to create a script which enforces who the recipient will be?
I.e. if you had two parties who had locked funds up under a 4-of-6 escrow, where the two parties are not the signatories required to release the funds and any four of the six escrow could sign to release to either party. Could the script be set up such that it can only be released to party 1 or 2. Because under this scheme four of the escrow could conspire to send the funds to an address other than one of the party address?
If you want to do it in the protocol level, the answer is no. If you just want the effect but don't care how it is done, DannyHamilton has suggested. |
|
|
|
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 |
|
|
|
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. 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. 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 ? 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. 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_attacki.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 |
|
|
|
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. |
|
|
|
The private key is certainly invalid. One more reason NOT to use blockchain.info wallet (and they are delisted from bitcoin.org already) |
|
|
|
However, it was under my impression that the original proposal was about remembering an address that you previously set up. The goal is to express the bitcoin address of someone in 4 words, given that it is on the blockchain. The BIP morphed into a general way of referencing any output. Which is compatible with the initial goal, and do not require a special "publishing step" for things already in the blockchain. hhanh00, I like the fact that your proposal needs less words and is easier to implement though. For example, people may want to use a mnemonic address to replace txid in daily use but the outputindex may not be <4. One particular useful case is for stealth address payment. The payer may use mnemonic address to help the payee to locate the output If people want to use mnemonic address to reference a txid, then I would say that the limitation of the txo count does not matter. If the user knows that it is a transactionId, he will just ignore the 2 bits of txoindex. Do you see another use case which might limit the usage ? It is true that mostly what is published in the blockchain today use less that 4 txo, would we severly limit use cases by using a fixed 2 bit for txo index ? With checksum=20bits and blocks with =< 2048 txs, my proposal already guarantees a 5-word address for the first 4 outputs of any tx, same as hhanh00's. If your code gives you a 6-word address, there must be something wrong. I can't see any reason not to allow people to encode the 5th output. With techniques like coinjoin, future transactions may have many outputs. Bitcoin is in its infancy and we won't know how people will use the blockchain in the future. |
|
|
|
Since you make the 'reference' transaction, you can make one that has a low number of txo. Let's say your txo index has to be < 4. 2 bits are enough to encode that offset. You want 20 bits of checksum so txo index and checksum fit in 22 bits or 2 words.
The block height is encoded with a continuation bit and either 20 or 31 bits for a total of either 21 bits if height < 2^20 (~1 million) or 32 bits if above but lower than (2^31). Add the version bit and it comes exactly to either 2 or 3 words.
TxIndex is simply encoded as words.
Recap:
# first part
- version bit: always 0
- length indicator
- if 0: use 2 words
- if 1: use 3 words
- block height
# 2nd part - always 2 words
- txo index: 2 bits
- checksum: 20 bits
# remaining words
- tx index
For any reference tx below index 2048 before height 2^20, it is guaranteed to be 5 words. The format is pretty constant and doesn't rely on txcount or the number of txo in the reference tx. Moreover, generation and parsing is straight forward.
Without the ability to encode all outputs in the blockchain, the use of such mnemonic address is highly restricted. For example, people may want to use a mnemonic address to replace txid in daily use but the outputindex may not be <4. One particular useful case is for stealth address payment. The payer may use mnemonic address to help the payee to locate the output |
|
|
|
I'll implement that during next week + provide a public service that other people can play with it.
I'll also copy your BIP + what we talked about on github.
I'm thinking if we should allow encoding of tx inputs with this scheme. Not sure if it is really useful. It could be done with 2 ways: 1. Put all inputs behind outputs. If there are 6 outputs and 3 inputs, index 0-5 will be the outputs and 6-8 will be the inputs. This won't affect the length of output addresses but input addresses may need more words. 2. Use 1 bit to denote input/output. This may increase the length of output addresses |
|
|
|
How the current implementation addresses the following criticism?
Addresses should generally not be reused. Reusing addresses harms the your security and privacy as well as the privacy of all Bitcoin users. Extensive address reuse contributes to systemic risks which endangers the system (what happens when RPG wielding ninjas show up at mining farms with demands to not mine transactions belonging to their enemies? If regular transactions are conducted so that they are indistinguishable to their author's enemies we never need to find out). While the community may not go so far as to prohibit reuse, building infrastructure that rewards it is not a good plan.
The current implementation does not restrict the type of output. It applies to any scriptPubKey. So people may, for example, 'register' stealth address with OP_RETURN. This implementation could also replace txid in daily use. It is even better than txid because it directs to a specific output in a tx. These short addresses are immediately subject to lookalike attacks-- a popular address is "wolf larceny tape butter" ... great, I go and create "golf larceny tape butter", "wolf larceny ape butter", "wolf larceny tape butler" and so on... I spam these clones out in various places or just trust human error to guide things along, and now I'm receiving funds from other people. We don't even need an attacker here, all outputs are constantly being assigned addresses, the space of working addresses dense-- instead of the very intentionally sparse case which we have with addresses today where its nearly impossible to send to an incorrectly entered address.
With adequate checksum bits, the odds of successful lookalike attacks is extremely slim. Even a miner could not try to mine a "vanity address" because they have to discard successful block hash for such vanity address mining (blockhash is part of the checksum) As you note, the security here is totally undermined by a reorg. So beyond chance reorgs breaking things for people and causing their funds to go off to be lost in space, now there is a great incentive to reorg that didn't exist before. (there also is some fun nuisance perversion like miners selling high value vanity positions in blocks with this particular scheme; spamming up the chain to make sure to register the really goods one, sometimes requiring large indexes.).
A reorg will make the checksum invalid. The address is safe to use even with only 1 confirmation. As mentioned, it is not possible to mine a vanity address One could not resolve these addresses without a copy of the entire blockchain or at least a forever growing unprunable database (as with firstbits) which would need to be accessable to each and every wallet. In practice most people would depend on centralized services to resolve these (as they did with firstbits), and in practice the services will eventually return wrong results, even without intentional fraud (as with firstbits). Of course, any of these services would be prime targets for compromise; a well timed replacement could redirect huge flows of funds.
It is SPV verifiable. In practice, an SPV client will ask a centralized service to resolve, and to provide the compact proof This also requires a separate registration step, which reduces the scalability of the system due to additional overhead, and makes the system less instant gratification. You end up with something where you have to pay fees to establish an 'identity' just to receive funds to pay the fees with. Necessitating multiple use modes.
People could do it when they are doing real transaction, so the marginal cost and harm is lowered |
|
|
|
I'm understanding now how you want to encode y and z !
Good job, this is awesome !
Modifying my code...
I don't have a rigorous proof but I believe this is not only a one-to-one function, but also the most efficient way to encode. Assuming a minimum checksum size of 19, in every block before 1,048,575, there must be at least 4 4-word addresses: the first output of the first 8 txs in the block After block 1,048,575, only the first output of the coinbase tx is 4-word. |
|
|
|
The raw address without checksum is 00110101 00001001 01010|000 00000000| 0000000 Calculated checksum is 26. 6 words. "arm voyage width veteran palm tattoo" There is something wrong with your code It is txIndex 0 and outputIndex 0, so y min = ceiling(log(txIndex + 1, 2)) = 0 z min = ceiling(log(outputIndex + 1, 2)) = 0 w = ceiling((x + ymin + zmin + c + 1)/11) = 4 (if c is 20) y1 is a big number because there is a lot of txs, but y2 = 11w-1-x-c = 2, and it is not smaller than y min, so y = 2; z1 is a big number because there is a lot of outputs, but z2 = 11w-1-x-y-c = 0, and it is not smaller than z min, so z=0; so it could be done with 4 words, including 2 bit of txIndex, 0 bit of outputIndex, and 20 bits of checksum |
|
|
|
|
Show Posts
