...
Here's another snippet of wisdom from when I'm trying to explain the odds of guessing a private key:
Cheat code to convert 2^x to 10^x: reduce the exponent by 3 or 4 (2^3 = 8; 2^4 = 16)
2^160 is (roughly) the same as a 1 with 156 zeros.
No. You have to divide 160 by 3 or 4. 2^160 = 1461501637330902918203684832716283019655932542976 like 1 with 48 zeroes. |
|
|
|
EDIT:
Non vorrei dare un dato scontato, ma in termini grezzi, la forza che è occorsa a Bitcoin per passare da $ 1 a $ 100, non è la stessa che occorre per passare da € 7.000 a $ 700.000...
Saresti in grado di fornire una stima della differenza tra i due casi? Quanto denaro in più dovrebbe intervenire nel secondo caso rispetto al primo? E in generale come si fa a fare una simile stima? |
|
|
|
Are you trying to protect against ransomware or other malware that locks you out of your computer? An offline digital backup is sufficient. You could use a hard drive that you backup your whole PC to every once in a while. Or use a remote storage service. You should also encrypt it. To protect against that case, you should be backing up your entire PC anyways, so making an additional physical backup to protect against it doesn't make that much sense.
Are you trying to protect against your house burning down (or some natural disaster) destroying everything in it? Well, your physical paper backup isn't going to stand against a fire. So in that case, again, a digital backup to a remote storage service. You could use a sturdier physical storage medium like metal, but good luck finding it after your house burns down. But it could still be destroyed or rendered unusable by damage. Yes, you could send that physical backup to somewhere else to be stored, but then you need to trust that whoever you are storing it with does so securely, and that that place isn't also destroyed. At least with a remote digital backup, you can be certain that the service provider is backing up their stuff so if their data center is destroyed, your data will still accessible. And you can encrypt it so it will be secure.
...
So why would making a physical backup be a bad idea? Well, it's another thing to keep track of, another thing to verify still works. And most people aren't going to encrypt their physical backups (because the UX for doing that sucks). So if you lose that backup or it gets stolen, you'll need to go through the hassle of making a new wallet and moving all of your coins there. Otherwise you risk your coins being stolen. So why risk that? Just make a digital backup instead.
In general, I don't really recommend using paper backups if you are using just a software wallet. There are so many other things in a wallet that are necessary for working, more than just private keys. The wallet file provides those things, so really you should be backing up the wallet file, not just the private keys.
If you're using a hardware wallet though, then yes, making a paper offline backup makes sense. The seed is all you need to restore a hardware wallet, but is not enough to restore a software wallet, you need to have both the hardware wallet seed and the wallet file data to truly restore your wallet. But it doesn't make sense to digitally backup the hardware wallet's seed since the whole point of a hardware wallet is to have a kind of airgap. So a physical backup makes sense there. But, as mentioned earlier, you still need to protect against that backup being lost or destroyed.
To encrypt a digital backup you need to create and store a passphrase. Where do you store this passphrase? Eventually "making a backup" comes down to store a passphrase, and you cannot store it as is using a remote service. You need then: 1) a digital encrypted backup on a remote storage service + 2) a passphrase on a physical backup |
|
|
|
ti rispondo un pò io visto che avevo iniziato a farlo, il funding di bitfinex è appunto il lending di poloniex o altre piattaforme.
bitfinex rispetto ad altri, offre lending su molte più monete. Vale la pena? Ni
nel senso, varrebbe la pena se holdi quelle monete, ma il rischio principale è che i fondi restato su finex e io non mi fido assolutamente.
Dipende anche dai tassi, alle volte trovi dei tassi molto alti (anche sulle valute fiat) e allora uno potrebbe permettersi di rischiare.
mentre sto scrivendo, il tasso dei monero su finex è del 42 % annuo, quindi magari uno ci fa un pensiero.
altro problema è che il fundung/lending, può durare molto meno del previsto, se la posizione di chi lo ha preso supera i limiti, il prestito si chiude.
Ho trovato la pagina con i tassi: https://www.bitfinex.com/statsEUR 0.0268% (al giorno) BTC 0.0042% (al giorno) XMR 0.0246% (al giorno) https://support.bitfinex.com/hc/en-us/articles/360024039494-What-do-I-get-when-I-offer-Margin-Funding-Si ottiene molto di più prestando monete fiat o Monero che btc. Immagino che per prestare crypto non sia necessario KYC, mentre per gli euro sì. |
|
|
|
1) how does Armory generate the change addresses?
Grab the next unused address in the chain The 'next unused' means the next address in the chain or the first address without tx? Example: I press "Receive Bitcoins" and I get the address A, then I press it again and I get the address B and someone sends bitcoins to the address B. If I spend bitcoin from B, A is still available as change address or Armory grabs another address C? |
|
|
|
Grazie per il link. Leggo che si può scegliere tasso di interesse e durata. Normalmente quanto si prende a settimana? |
|
|
|
Da allora faccio solo funding su Bitfinex.
Come funziona, è possibile avere degli interessi prestando dei btc? Tassi? Rischi? |
|
|
|
Visto che è tempo di bilanci è sempre utile andare a rivedere come tutto è iniziato: https://satoshi.nakamotoinstitute.org/emails/cryptography/threads/1/Gli interventi di Satoshi sono tutti firmati, quelli degli altri iniziano con il carattere ">": I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. The paper is available at: http://www.bitcoin.org/bitcoin.pdfSatoshi Nakamoto >You will not find a solution to political problems in cryptography. Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years. Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own. Satoshi >I think the real issue with this system is the market >for bitcoins. >Computing proofs-of-work have no intrinsic value. We >can have a limited supply curve (although the "currency" >is inflationary at about 35% as that's how much faster >computers get annually) but there is no demand curve >that intersects it at a positive price point. >I know the same (lack of intrinsic value) can be said of >fiat currencies, but an artificial demand for fiat >currencies is created by (among other things) taxation >and legal-tender laws. Also, even a fiat currency can >be an inflation hedge against another fiat currency's >higher rate of inflation. But in the case of bitcoins >the inflation rate of 35% is almost guaranteed by the >technology, there are no supporting mechanisms for >taxation, and no legal-tender laws. People will not >hold assets in this highly-inflationary currency if >they can help it. Increasing hardware speed is handled: "To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases." As computers get faster and the total computing power applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future. The fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase. Coins have to get initially distributed somehow, and a constant rate seems like the best formula. Satoshi Nakamoto > Sorry about all the questions, but as I said this does seem to be a > very promising and original idea, and I am looking forward to seeing > how the concept is further developed. It would be helpful to see a more > process oriented description of the idea, with concrete details of the > data structures for the various objects (coins, blocks, transactions), > the data which is included in messages, and algorithmic descriptions > of the procedures for handling the various events which would occur in > this system. You mentioned that you are working on an implementation, > but I think a more formal, text description of the system would be a > helpful next step. I appreciate your questions. I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec. You're already right about most of your assumptions where you filled in the blanks. Satoshi Nakamoto >This does not work - your proposal involves complications I do not think you have thought through. >Furthermore, it cannot be made to work, as in the proposed system the work of tracking who owns what coins is paid for by seigniorage, which >requires inflation. >This is not an intolerable flaw - predictable inflationis less objectionable than inflation that gets jiggered around from time to time to transfer >wealth from one voting block to another. If you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee's side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block. Satoshi Nakamoto Tra le altre cose, come mi è stato fatto notare in quest'altro thread, Satoshi prima scrisse un programma funzionante, poi il famoso paper. E molte regole/idee gli sono venute anche dopo il paper. Si tratta di un approccio estremamente pragmatico. La cosa è particolarmente interessante, perchè fa notare un aspetto fondamentale di bitcoin: non ci sono (contrariamente a quanto si possa pensare) delle regole scritte e condivise su qualche documento alle quali attenersi, tutte le regole sono direttamente implementate nel programma. E 'il' programma è in realtà un insieme di versioni diverse che cambiano nel tempo. Man mano che si 'evolvono' le versioni di Bitcoin Core (o anche di altri client) evolvono anche le regole, in modo più o meno esplicito. Questa 'evoluzione', che ha sollevato tanti dubbi sul concetto di 'consenso' e di regole condivise e immutabili (suggerisco ad esempio la lettura di questo articolo: https://blog.conformal.com/the-bitcoin-consensus-red-herring/) in realtà è un punto di forza di bitcoin. Bitcoin infatti in un certo senso assomiglia a una specie vivente, con un dna che si modifica autonomamente (non c'è scritto da nessuna parte come deve funzionare un essere vivente) nel tempo per meglio adattarsi alle circostanze che mutano nel tempo. Ha un nucleo forte di regole che probabilmente resisteranno molto a lungo, mentre altre devono essere fragili e modificabili per poter garantire la sopravvivenza delle prime e il miglioramento del sistema in generale. Pur riconoscendo a Satoshi la genialità della sua invenzione, l'aspetto forse più geniale non sta tanto nell'aver previsto tutto a tavolino (cosa che non è avvenuta), ma nell'aver avviato un sistema in grado di modificarsi e adattarsi migliorando con il passare del tempo e con gli apporti di tutti (basta vedere l'immagine del post precedente al mio) Bitcoin ha cioè la proprietà di essere "antifragile", è un sistema che tende a migliorare anche sotto attacco perchè continua ad assorbire nuove informazioni e non si basa affatto sulla preveggenza/onniscienza del suo ideatore. Ama la volatilità e l'incertezza, non nel senso del prezzo, ma perchè sembra trarre forza dagli imprevisti che possono capitare (dai vari "cigni neri" tipo recessioni economiche, ...). E' robusto e resiliente. Per il concetto di "antifragile" introdotto da Taleb un riferimento è questo: https://st.ilsole24ore.com/art/cultura/2012-11-19/antifragile-evitare-eccessive-precauzioni-121759.shtml?uuid=Ab2rxQ4G&refresh_ce=1 |
|
|
|
I was reading this page: https://en.bitcoin.it/wiki/Protocol_documentationin particular this sentence caught my attention: The Bitcoin protocol is specified by the behavior of the reference client, not by this page. In particular, while this page is quite complete in describing the network protocol, it does not attempt to list all of the rules for block or transaction validity.
All the rules we know (21 million btc, ...) come from the first implementations of the Satoshi client? There is not a white paper for all the validation rules? The Satoshi's paper lacks of many details. |
|
|
|
I'm trying to understand in more detail how it works the Armory's derivation scheme. Let oiae hiij eauw ekhd aeuu wdau iirh tksu astr
wjjj dfuw hfej nwsn naoi rwgs jeja unni kkku
be the Root Key printed on a paper backup (obviously I use it only to understand the mechanism ...) 'astr' and 'kkku' should be only to check errors at the end of each line, then I remove them and convert from the easy16 to hex format: EASY16CHARS = 'asdf ghjk wert uion'.replace(' ','')
plainRootKeyEasy : oiaehiijeauwekhdaeuuwdauiirhtksuwjjjdfuwhfejnwsnnaoirwgsjejaunni
NORMALCHARS = '0123 4567 89ab cdef'.replace(' ','')
plainRootKey : ed095dd690c8975209cc820cdda5b71c866623c85396f81ff0eda8416960cffd (32 bytes)
I derive the chaincode from the Root Key: bin_root_key = plainRootKey.to_bytes(32, byteorder='big')
hash256(bin_root_key) = ddbed0169f589ff48ec32cb448dd16f5288a0719bb2454a15036b8575903ffda
chaincode = HMAC256(hash256(bin_root_key), 'Derive Chaincode from Root Key')
chaincode : 84444f1c8c83c9523f120fbae08fa47cb602342ce26b03a31d01dcf343e2e13e (32 bytes) (it is constant for the entire chain)
To pass from a private key (index N) to the next one (index N+1) I have to do a multiplication a * b mod n, where: n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
a = chaincode xor hash256(pubkey)
b = privkey (index N)
nextprivkey = a*b % n
nextpubkey = (a*b % n)*G where G is the generator of the secp256k1 curve
nextpubkey = a*(bG) = a*P where P is the public key (index N)
The parameter 'a' (together the related address) is stored in the multipliers.txt file in .armory directory. 'a' is like a sort of private key of the address N+1 computed respect to the previous public key N instead of the generator G. In this way the wallet offline can generate these particular private keys (multipliers) only from the first (root) public key and the chaincode. We get all the public keys (as multiples of the root public key) and then all the addresses without using the real private keys (because to get an address we need only a public key, the private key is not necessary). public keys chain: root public key P1 -> a1*P1 = P2 -> a2*P2 = P3 -> a3*P3 = P4 -> ... private keys chain: root private key a -> a*a1 % n -> a*a1*a2 % n -> a*a1*a2*a3 % n --> ... If only one private key N and the chaincode are revelead, then Private key N with the chaincode will let you compute all private keys beyond N. To compute private keys prior to N, you need all public keys preceding N as well. Both chaincode and public keys are considered known data (as they lay on online computers), hence the generalization that revealing a private key within the chain is as good as revealing all private keys in the wallet.
Returning to the computations, in my particular case: chaincode : 84444f1c8c83c9523f120fbae08fa47cb602342ce26b03a31d01dcf343e2e13e
pubkey : 0445563be187fb75440607375558bcc0676e84b30040a2068747f94f82e78dfeb911299531610d0ec3a5602350a643dadd9af51b21f2c33ad446ea9c9f099c61e1
hash256(pubkey) : 12f1ed57097159dbb709229e48aafb2e080f6f0dfe8213b7fa836942e4aba08
a = 856b51c9fc14dccf84629d9304050bce5682c2dc3d83229862a9ea676da85b36
b = ed095dd690c8975209cc820cdda5b71c866623c85396f81ff0eda8416960cffd
nextprivkey = 27dcda057ab1f2c114da68f3fb5d1c42456ccf76b606064fdef4ca38167fb508
Then the first private key (and address) of this wallet is: privkey : 27dcda057ab1f2c114da68f3fb5d1c42456ccf76b606064fdef4ca38167fb508
address : 1AyEzG2REn9szCTimJZjZx9X2TJ25DfAqW (base58)
address : 6d5c1a1398b2a869535afda83c3ca62e6537fb6f --> first 5 bytes: \x6d \x5c \x1a \x13 \x98
Id wallet = binary_to_base58(ADDRBYTE + firstAddr.getAddr160()[:5])[::-1]
Id wallet = binary_to_base58(b'\x98\x13\x1a\x5c\x6d\x00')
Id wallet : 2JjGQxFtK
If I apply again the same scheme, I get the other addresses: #1 private key : 27dcda057ab1f2c114da68f3fb5d1c42456ccf76b606064fdef4ca38167fb508 address: 1AyEzG2REn9szCTimJZjZx9X2TJ25DfAqW
#2 private key : 94094ed331ca8fba87e9f223e71df6945aac5bde1b8523584d828b596f3bd167 address: 1BU1WGcrkNTRSzLVQnEYeoWHXecGYK9YBv
#3 private key : 80aced7c27ac69b5f359572773c45be903d90012f96b8ae7da398242c2019c47 address: 12JSLGgYVY8EdeF1dfZWpSspLVE2A4Sms8
#4 private key : db5099b13a7a0309e705e2d6166349ff049cfb95203ddc66b652ae61bd5aac84 address: 1CZqeKPka88ARov1CGXKugU7WEmgENs3My
#5 private key : f79d421ee19f9278cb802db35bf4df9ec14b57d4aef3ea70d8a659e4e6e8bd3e address: 1K85SqJVxJio5awb3kaCe1VN6vpsfXEXFV
...
#101 private key : f6c25c16b2bce422fd43c95cfafebc517def32ddbc71ec53259fe3670e863dac address: 18gK7fuU6ymxEdH1ngieiehK4GyzLXBAzy
I noted that Armory at the start generates a pool of 100 addresses. Each time I press the button "Receive Bitcoins", it generates another address (then there are always at least 100 empty addresses in the Address Pool). 2 questions: 1) how does Armory generate the change addresses? 2) when you restore a wallet from its Root Key, how many addresses are checked to retrieve the total balance? Maybe it tries until it finds at least 100 consecutive addresses without tx, or more? I did a test, it stops after 1000 consecutive addresses. |
|
|
|
This is not exactly the answer to my question - "Is there a number that creates a range that makes up 100% of the pool in which the prefix is located?"
The answer was here: Search space size is not 173346595075428800, sometimes you have to generate more than 173346595075428800 addresses to get a match.
A group that creates 100% addresses where one of them will start with a given prefix has size 2^160 - 173346595075428800+ 1 (and I'm not considering the fact that there are 2^96 different private keys - means tries - for the same address).
in other terms: no, there is not such a number, or if you prefer there is but it is a very very large number, something like 2^256 - (2^160/difficulty)*2^96 where (2^160 / difficulty) is the size target (number of addresses with a given prefix, 2^96 is the average number of private keys to the same address). But nobody knows exactly how many private keys generate addresses with a given prefix, it is only a estimate! What the case looks like in case of difficulties 10054102514374868992
What percentage does this number specify? (I can't find an effective calculation method myself)
difficulty = 10054102514374868992 = 2^(63.1) number of keys we have to use (= number of addresses we have to generate to get on average 1 match) target = 2^160 / 10054102514374868992 = 1.453637095147298e+29 = 2^(96.9) number of addresses in target difficulty * target = 2^160 (all addresses)! The difficulty is how much the set of all addresses is bigger than set of the target addresses. In this case: difficulty = set of all addresses / target set = 2^160 / 2^(96.9) = 2^(63.1) Smaller is the target, bigger is the difficulty to hitting it and viceversa. How to compute the probability? The formula (probability to hit a element in the target set in n tries) is: P(n) = 1-(1-p)^n where p = 1/difficulty (probability to get a match each try). In your case: p = 9.946 * 10^(-20) P(1) = 1-(1-p)^1 = p = 9.946 * 10^(-20) P(100) = 1-(1-p)^100 = 9.94 * 10^(-18) P(10054102514374868992) = 1-(1-p)^10054102514374868992 = 0.63 -> 63% P(2*10054102514374868992) = 1-(1-p)^2*10054102514374868992 = 0.86 -> 86% P(3*10054102514374868992) = 1-(1-p)^3*10054102514374868992 = 0.95 -> 95% P(k*diff) = 1-(1-p)^k*diff = 1- e^-k (this way is more simple to compute) If you want to know what is n to get P(n)=99% --> 1-(1-p)^k*diff = 1 - e^-k = 0.99 --> e^-k = 0.01 --> k = -ln(0.01) = 4.6 --> n = 4.6 * 10054102514374868992 P(4.6*10054102514374868992) = 1-(1-p)^4.6*10054102514374868992 = 0.99 -> 99% P(6.9*10054102514374868992) = 1-(1-p)^6.9*10054102514374868992 = 0.999 -> 99.9% and so on. |
|
|
|
When using splitkey, there is just a add of the specified public key at the beginning of the search. It should not bring a significant overload.
I will make further tests.
I thought it were slower (I didn't try, I read it somewhere in the thread). In this case there is no difference. |
|
|
|
I think it doesn't, but the goal is different: generate a vanity address on unsafe machine or delegate this work to others in a trustless way (indipendently from what VanityPool does).
There is already a split-key mechanism that allows this, do you have issue with it ? It allows this but you have to accept a lower speed: if your goal is to generate as fast as possible a vanity address on unsafe machine (or to pay less a third part exploiting completely its hardware) the spli-key mechanism is not the best option. |
|
|
|
Keep in mind that you shouldn't treat soft derived BIP32 private keys with any less care, as the same property applies: One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys.
It is good practice to not reveal your wallet's private keys, regardless of the derivation scheme. Consider the wallet compromised if you did, and move the funds out. Thank you for the clarification. |
|
|
|
Yes why not.
I plan to change the implementation of the -sp option. Rather using a mod ModAdd for the final priv key reconstruction, it would be simpler as you suggest to use ModMul and this method should be independent of symmetry or endomorphism optimizations. It will also simplify the implementation but I don't know if VanityPool supports ModMul for reconstruction. I think it does, but I'm not sure.
I think it doesn't, but the goal is different: generate a vanity address on unsafe machine or delegate this work to others in a trustless way (indipendently from what VanityPool does). |
|
|
|
Hi,
The difficulty is the search space size.
A difficulty of 173346595075428800 means that you have a probability of 1/173346595075428800 to find the result after 1 try.
After n tries, you can compute the probability to reach the desired address by using Bernoulli.
P(n) = 1-(1-1/173346595075428800)^n
I am asking because I have scanned the range of keys being the number given by Diff, but I have not found a solution. 1. What is the remainder of the range that I should scan to find the answer? 2. The fact that I did not find the correct key despite this is not the reason for the error in the code? I already answered to you: difficulty is not the range you should scan to find the solution at 100% : you have in the above example P(173346595075428800) = 1-(1-1/173346595075428800)^173346595075428800 = 0.63 --> 63% ( = 1-1/e), not 100%! That means that only 2 times each 3 you will find the solution in a range = difficulty. |
|
|
|
Where is the exact procedure now to derive the private key chain from the wallet's root private key? I use a wallet created in 2013. I'd like to see an article that explains how it works. I read this answer too: https://bitcointalk.org/index.php?topic=354667.msg8570465#msg8570465and I found out that a wallet is compromised if I reveal a single private key! |
|
|
|
|
Show Posts
