I understand and it varies depending on the transaction we are doing. For example, it is obvious the we should wait for about 50 - 60 confirmation if we are dealing with a huge amount of money maybe around millions of dollars or 70 confirmations if I am selling an empty lot.
6 confirmations are definitely enough for high value transactions. I see but I am wondering where did the second transaction go if it was the first transaction to get included in the blockchain. Why is the reseller does not receive the equivalent amount of bitcoin? Does it mean the duplicated block was sent to himself?
A transaction does not get included into the blockchain. First, it gets broadcasted and stays in the mempool of every single node. Then a miner can include it into a block. From this moment on, this transaction is confirmed. The transaction never was confirmed. It was just broadcasted (comparable to saying "i want to transfer X BTC to Y"). Then the attacker broadcasted another transaction with a higher fee, which ended up being included into a block. I understand that one of the double spending attack is by increasing the tx fee of the second block. So it means there is no such thing like "cancelling the transaction" whenever it is broadcasted in the network.
The TX fee will be increased with the second transaction. And yes, you can't actively cancel a transaction. You can try to broadcast another transaction which hopefully will get confirmed instead of the first one. |
|
|
|
Also kommt man deiner Meinung nach vom target zur Difficulty?
Bei der Berechnung des nötigen PoW kommt die Difficulty, soweit ich weiß, garnicht vor. Das ist einfach nur ein Wert zur Veranschaulichung. Ja, ich hatte das einfach von dir übernommen, deshalb hat sich hier ein Fehler eingeschlichen, mein Fehler.
Es gehört natürlich umgedreht, also:
new_difficulty = old_difficulty * (target_timespan / timespan)
Das wäre aber nicht das, was im source code steht: bnNew.SetCompact(pindexLast->nBits);
bnNew *= nActualTimespan;
bnNew /= params.nPowTargetTimespan;
1) Setzte bnNew auf old_target 2) old_target * timespan 3) (old_target * timespan) / target_timespan Daraus ergibt sich: bnNew = old_target * timespan / target_timespanbnNew ist hier zweifelslos das Target. |
|
|
|
Based from the answers above, your friend needs to wait for at least six confirmation before sending the fiat equivalent of bitcoin.
Not necessarily, no. Six confirmations are recommended to be close to absolutely sure the transaction went through. For Amounts as low as 1k$, you definitely don't need to wait for 6 confirmations. Why? because if the transaction is under 3 confirmation, the sender can technically cancel the transaction by duplicating the first transaction which means the duplicate block has to be the same input similar to the first transaction.
The sender can never cancel the transaction. What he can do is to create a new transaction spending the same inputs (if the replace-by-fee tag is set on the first transaction). The miner decide which transaction they will include into the block. Usually its the one with the higher fee. But after it got included into a block, this is no longer possible. There are multiple ways of double spending attacks. But the easiest one is the replace-by-fee method, which probably has been used here. More sophisticated exist, where it even shows a confirmation. But this costs you a whole block reward to achieve. Therefore (with high value transaction) you should wait for multiple confirmations (6 to be on the very safe side). |
|
|
|
Daraus ergibt sich die Formel: new_target = old_target * (timespan / target_timespan)
Das ist der Algo zur Diff- Anpassung. Daraus ergibt sich die Difficulty, nicht das target. Und aus der Difficulty wird dann das target berechnet. Dann ergibt sich daraus halt new_difficulty = old_difficulty * (timespan / target_timespan) und dann kommt man über: new_target = max_target / new_difficulty wieder auf das target. Das würde keinen Sinn machen. Wenn das die Formel zur Difficulty sein sollte, bedeutet das, dass wenn die letzten 2016 Blöcke doppelt so lange gebraucht haben, wie eigentlich gewünscht ( timespan = 2*target_timespan), die difficulty verdoppelt wird: new_difficulty = old_difficulty * 2. Das passt so aber nicht, die difficulty muss niedriger werden. Das Target muss größer werden. Daher passt : new_target = old_target * 2Somit ergibt sich schlussfolgernd, dass da das Target, und nicht die Difficulty, berechnet wird. |
|
|
|
You can use escrow always or much better use third party exchange every time when you are buying/selling Bitcoin.
Did you even read the OP? All he had to do is to wait for a single confirmation. |
|
|
|
Reseller were much greedy and he wasn't not aware about double spent.
What you meant to say was: Reseller didn't know such thing as confirmations exist and that transactions are only final after receiving at least one confirmation. He does not know how Bitcoin works, nor how to use it. All he wants is to make money from it.A transaction is not completed until it got at least 1 confirmation. I really believed everyone knows that already.. but apparently not.. |
|
|
|
Aber das target wird doch über die neu errechnete Difficulty bestimmt.
Eigentlich wird die difficulty dazu garnicht benutzt. Die Funktion ( https://github.com/bitcoin/bitcoin/blob/0.20/src/pow.cpp#L49) sieht so aus: unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params)
{
if (params.fPowNoRetargeting)
return pindexLast->nBits;
// Limit adjustment step
int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
if (nActualTimespan < params.nPowTargetTimespan/4)
nActualTimespan = params.nPowTargetTimespan/4;
if (nActualTimespan > params.nPowTargetTimespan*4)
nActualTimespan = params.nPowTargetTimespan*4;
// Retarget
const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);
arith_uint256 bnNew;
bnNew.SetCompact(pindexLast->nBits);
bnNew *= nActualTimespan;
bnNew /= params.nPowTargetTimespan;
if (bnNew > bnPowLimit)
bnNew = bnPowLimit;
return bnNew.GetCompact();
}
Daraus ergibt sich die Formel: new_target = old_target * (timespan / target_timespan)
|
|
|
|
Cold storage in the context of Bitcoin refers to storing Bitcoins offline and spending without the private keys controlling them ever being online. This resists theft by hackers and malware, and is often a necessary security precaution especially dealing with large amounts of Bitcoin. Consequently, any hardware wallet that comes into contact with the Internet can no longer be considered cold wallet. According to your definition, a hardware wallet IS a cold wallet. The private keys never touch an online device. They are isolated in a secure element (speaking about ledger). The MCU gets in touch with an online device. This theoretically makes a ledger nano a cold wallet, but not a trezor. But i know what you mean.. I wouldn't call a hardware wallet a cold wallet. But its not a hot wallet either. IMO that is a mixed form between a hot- and a cold wallet and has its own category. @OP What kind of cold wallet do you want? How frequently do you transact? Do you want the private keys to be stored on an offline computer? Or is a paper wallet a better option for you? Those are questions you have to answer for yourself. |
|
|
|
I love that of creating a properly generated, bip38 encrypted paper wallet.
Please make sure to NOT use any website for that. Doesn't matter whether offline or online. This is bad practice. Preferably use some open source software/script to generate them (e.g. use your operating systems RNG to create a private-/public keypair or just use electrum). With small amounts it probably wouldn't matter too much whether they get stolen or not, but its always better to not use a website. |
|
|
|
Die Änderung des target_value erfolgt über die gerade berechnete difficulty. new_target = old_target / new_difficulty Das neue Target wird wie folgt berechnet: new_target = old_target * (time taken for the last 2016 blocks in seconds / 1209600 seconds)
Es wird jedoch nicht mit der difficulty multipliziert oder dividiert. Das lässt sich auch ganz einfach ohne groß zu rechnen zeigen: Angenommen, die Hashrate blieb über 2 Wochen konstant und die Zeit zwischen den Blöcken lag bei exakt 10 Minuten => Es wird also nichts geändert. Nach deiner Formel new_target = old_target / new_difficulty, müsste damit das neue target = das alte target ist, die neue difficulty 1 sein. Und das kann nicht stimmen. Die Difficulty müsste sich einfach nicht ändern, was bedeutet sie müsste bei 14715214060656 bleiben.
X / 14715214060656 != X
|
|
|
|
Some software developers will publish a list of the sha256 or MD5 hashes, and sign the list with a PGP key, so you know the hashes are authentic. I couldn't agree more with that. Hackers cannot fool us if the official site gives us the hash of their software. Not if the hacker also hack the official website, add tampered installer with it's hash on the website. And yes, it happened before on popular software/OS, such as Linux Mint OSThe point is that these hashes are signed using his PGP key. Hosting the software and it hashes on the same website / same place obviously is prone to be abused. But the crucial factor is that they are signed with his PGP key, which is not stored on the server. Verifying the signature of the txt file containing the hashes would then only passed if these are indeed the hashes produced by the developer. |
|
|
|
Am wenigsten verstanden habe ich bisher das da oben.
Ok, sorry. Ich versuchs noch ein mal. Ich weiß das eine Prüfsumme gefunden werden muss.
Diese ergibt sich aus der Prüfsumme des letzten Blocks und den aktuellen Transaktionen.
Es ist nicht wirklich eine Prüfsumme. Hashes werden oft als Prüfsumme verwendet, aber nicht in diesem Fall (bei der Generierung eines Blocks). Es muss einfach ein Hash errechnet werden. In den Hash fließen verschiedene Sachen mit rein, unter anderem der Hash des letzten Blocks. Außerdem fließt eine Nonce (Number only used once) mit ein, diese kann verändert werden um so einen komplett anderen Hash zu erzeugen. Dies spielt bei der Suche nach einem gültigen Hash eine wichtige Rolle. Zu deinem Beispiel:
Wenn die Difficulty bei 15.000.000.000.000 liegt, bedeutet es, dass es 15.000.000.000.000 mal schwieriger ist, als bei der niedrigsten Difficulty.
Was GENAU ist denn schwieriger? Der Hash selbst (also der Rechenweg)? Nicht der Hash selbst, sondern einen Hash zu finden, der gültig ist. Also wenn wir das alles mal vereinfachen. Nehmen wir folgendes an: Die Hash funktion liefert einen 4 bit output. Target wird ebenfalls durch 4 bit definiert. Das niedrigste Target wäre 0001. Das höchste 1111. Bei einem Target von 1111, beträgt die Difficulty 1 Bei einem Target von 0111, beträgt die Difficulty 2 (relative Schwierigkeit zur niedrigsten difficulty) Es ist also 2 mal schwieriger einen Hash zu finden der unter dem Target 0111 = 7 liegt als unter dem Target 1111 = 15 (vereinfacht gesagt). Wenn das Target bei 0101 liegt, muss ein Hash gefunden werden der kleiner ist. Also wäre 0100 und 0011 z.B. gültig. 0110 aber nicht. Je größer das Target ist, umso leichter ist es eine Zahl die kleiner ist zu finden => Desto niedriger die Difficulty. Daraus ergäbe sich, dass das Target bei 2224/difficulty = 1797329777810042652977801005801308711575809628169371498.7 liegt. Der erzeugte Hash muss also einen Wert niedriger als das Target aufweisen um als valider Block anerkannt zu werden.
Die ganze Zeit krieg ich erklärt der Hash muss höher sein als die Diff und nun das. Bin echt verwirrt. Das ist falsch. Die Difficulty ist nur ein relativer Wert. Der Hash muss niedriger als das Target sein. Target und Difficulty stehen in direktem mathematischen Zusammenhang. Aber das eine ist eine relative Angabe und das andere das "in der Praxis genutzte" Target. Bei einer Difficulty von 15.000.000.000.000 braucht man im Durchschnitt 232 * difficulty = 64.424.509.440.000.000.000.000 Versuche um einen gültigen Hash zu finden.
Mit 45 GH/s benötigst man dafür ca. 45398 Jahre.
Es sei denn man hat Glück und trifft im ersten Versuch!  Desswegen ja auch "im Durchschnitt"  Ich nehme schwer an, dass ich den ein oder anderen hier bereits nerve, aber ich gebe nicht auf
bis ich es wirklich verstanden habe.
Kein Problem. Falls es immernoch unverständlich ist, versuch genau zu erklären wo  |
|
|
|
~snip~
Die Difficulty ist der Quotient aus dem maximalen Target und dem aktuellen Target. Also die relative Schwierigkeit im Vergleich zur niedrigsten Difficulty (= höchstes Target). Das Target wiederum ist eine zahl, die den höchsten Wert für einen Hash angibt, damit dieser als valide anerkannt wird (blockheader). Das höchste Target entspricht der niedrigsten Difficulty. Das bedeutet, dass das niedrigste Target, die höchste Difficulty darstellt. Beide Zahlen sagen das gleiche aus. Zu deinem Beispiel: Wenn die Difficulty bei 15.000.000.000.000 liegt, bedeutet es, dass es 15.000.000.000.000 mal schwieriger ist, als bei der niedrigsten Difficulty. Daraus ergäbe sich, dass das Target bei 2224/difficulty = 1797329777810042652977801005801308711575809628169371498.7 liegt. Der erzeugte Hash muss also einen Wert niedriger als das Target aufweisen um als valider Block anerkannt zu werden. Bei einer Difficulty von 15.000.000.000.000 braucht man im Durchschnitt 2 32 * difficulty = 64.424.509.440.000.000.000.000 Versuche um einen gültigen Hash zu finden. Mit 45 GH/s benötigst man dafür ca. 45398 Jahre. |
|
|
|
And how do I know that bitaddress.org doesn't store its private and public keys in database? What's the point of that site anyway?
Actually, if you are using the site.. you don't know. I would discourage from using such a site to generate a paper wallet. Doesn't matter whether downloaded or online. You can create a private/public keypair by using electrum or even via the linux command line using openssl. And that is why you do the process offline, so you avoid any issues.
You can download the website files (see GitHub respository) and run them on an air-gapped PC. This will ensure that the keys are not sent anywhere. While the private keys might not get sent anywhere, the random number generator could be manipulated or flawed. Especially when we are talking about javascript libraries. Generating them using electrum, which uses the os.random() python function which uses the operating systems default entropy generation method is the preferred way. |
|
|
|
How can a scammer fool the official site of electrum since it's owned by Thomas?
There are multiple ways to achieve that. Some would be: 1) Compromise the Web Server 2) Gain access to the Registrar account (gandi.net in this case) and change the DNS resolution to a different IP (server owned by the attacker) 3) Man-in-the-Middle: Either via malicious browser extension (still https) installed in your browser or via redirecting you to a http site without a certificate. 4) DNS Hijacking: Manipulating DNS Servers to resolve the URL to a different IP (server owned by an attacker) Verifying the signature (given that his PGP key is not compromised) does protect against these attacks. |
|
|
|
You don't have to worry about the Replace-by-Fee thing, this just means that the transaction can be replaced by another one with a higher fee before it is confirmed. This transaction already is confirmed, so everything is fine. It would be helpful if you could start with basic information: - What wallet are you using (and which version) ?
- Is your wallet connected ? Do you see an incoming transaction / balance ?
- Which address does belong to your wallet ?
|
|
|
|
What I was interested in was whether each device sold had some unique identification code, by which each device could be identified via the Internet.
According to ledger, no: There is actually no way to identify a given Nano S, there is no serial number, 2 nano S with the same seed are identical from technical perspective.
|
|
|
|
Do you think firmware updates would even be needed anymoe as soon as my PC is completely airgapped?
I think it would be more advisable to do so. Firmware updates don't only provide security updates, but also fix bugs and add new features. If you want to set up your cold wallet setup only once (i.e. install all necessary wallets and never update them), then you wouldn't need any firmware updates. But updating the firmware doesn't really do any harm. It might be possible that once in a while an update will create some problems, but those are usually fixed in a relatively short timeframe. Additionally, if you keep installing more wallets (for additional coins) or need to update those wallets, they might require an up-to-date ledger. If you have a backup of your seed (which you always should have), i'd say just update it once in a while. It has more advantages than disadvantages. |
|
|
|
|
Ich kenn mich mit EOS und Scatter zwar nicht aus, aber.. was spricht den an sich gegen Scatter ?
Es ist Open source und läuft auf allen Systemen.
Die Einrichtung scheint mir jetzt auch nicht all zu kompliziert zu sein, insbesondere da es einige Anleitungen und How-To's dazu gibt.
|
|
|
|
|
You need to use a wallet for each altcoin which allows you to sign and export transactions (just as electrum for bitcoin).
This most likely won't work without such a wallet. Especially shitcoins altcoins which are only accessible via ledger live.
I mean.. you probably could write your own application to communicate with your ledger, but this would mean quite some additional work.
|
|
|
|
|
Show Posts
