In step 1, A1 needs a reference to B to be published but B doesn't need any references at that point. A1 contains the hash of B. This means that A1 contains a fingerprint of the fields of B. This means that, excluding the signature, B contains everything needed to be broadcasted once it's signed. Such fields are input count, inputs, output count, outputs etc. So, before we even spend A1, we possess a transaction B which has B1. But, B must contain a reference to C, otherwise it won't be a valid transaction in the future (as B1 can be double-spent). We need to ensure B1 contains a transaction hash so that it can only be spent only by using that transaction. Thus, it is required to edit B and include C's hash into B1. Don't you see the loop? |
|
|
|
This discussion gave me the following idea: Betting for the next adjustment(s). How does it sound?  And 3 months ago the price was over $60k. Now it's $33k. In the same period, the difficulty has gone from 20 T to 26.6 T. Maybe their huge earnings from the ATH cover their current losses. Maybe we should wait for a little more to judge. I had read that a company invested nearly a billion dollars in mining equipment recently. Mempool.space predicts a -5% in the next adjustment. You mentioned two examples. If I gave you another 10, would it make my assumption more correct? Again, I can't know those external factors, but it's reasonable to assume that it's probable for the difficulty to drop if the price does a -50%. I chose those dates arbitrarily and they turned out to confirm my reasoning. How do you explain the similarity of the charts? But if an attacker is successful at creating their own chain which replaces the last 10 blocks, then they will receive the block reward for all 10 of those blocks in their new chain. True! So, the computational cost AND the block rewards should be less than the transacted amount to incentivize cheating, right? (Excluding the market's upheaval) |
|
|
|
Common sense might say so, but when has the network ever behaved in the way you would expect it to? On 1st of July, the equivalent of 1 BTC was around $35,000. On 1st of September, the equivalent of 1 BTC was around $47,000. Few days after the 1st of July, once the difficulty retargeted, it fell to 14,363,025,673,660.00. Around a week later on September, the difficulty went up to 18,415,156,832,118.00. This means that within this 2-months period, the price and difficulty went up by 25.5% and 22% respectively. The changes happen analogously, because the rise of the demand (which is the only thing that affects the price) increases the miners' profit. There are definitely factors that go against this such as state intervention, but judging by the two charts[1][2], my common sense works as a canon. [1] https://blockchair.com/bitcoin/charts/price[2] https://blockchair.com/bitcoin/charts/difficulty(Click on “All Time”) If miners are expecting the price to rise again in the future, then why would they turn off their miners now? Because there are also miners who don't expect that the price will rise. This brings equilibrium, I guess. You are incentivized to reverse the transaction as long as the amount you move is not covered by the new coinbase transactions. This is true only for the mining costs. Who knows the chaos which will prevail in the market once they find out you reversed a transaction, if they somehow manage to. I highly doubt if it's favoring you to reverse a transaction unless it exceeds astronomical amounts for one individual. (e.g., > 1000 BTC) |
|
|
|
There's no real evidence of that happening at the moment. There are many factors I don't examine which can change the final output, but my common sense says that if we have hard drops in price, we'll have similar drops in difficulty too. Aside from amount of money involved, there are few other consideration such as whether you could sue them for fraud/fraud attempt and how much trust you them. How can you sue someone if you had your Bitcoin transaction reversed? There's no evidence that it happened. Sorry, I don't think that I understand you. |
|
|
|
There are sites and people that suggest that it is good to wait for 6 confirmations before you can accept a bitcoin payment You should definitely wait for more than 1 confirmation if you're moving much money. For instance, you may have noticed that some exchanges require more than 1 confirmation if you're moving 10+ BTC. The payee has to ensure you're not incentivized to reverse the transaction. the hashes miners are producing reach all time high level again some days ago, this makes the blockchain to be getting stronger Off-topic, but I suppose due to the recent crash, the mining difficulty will drop hard. |
|
|
|
The first question is if the bitcoin if the blockchain suffer 51% attack, the bad miner will double spend some bitcoin. If the network is back to normal, will the coin that was double spend be reversed and everything again be correct to normal? How will the network return to normal? Assuming the dishonest miner disappears? The honest miners will continue mining the chain with the most work, which is the one the dishonest miner cheated successfully. I suspect there'll be chaos prevailing. I'll stop using Bitcoin at the time the game theory we all depend on, fails. According to what I read, that the bad miners will have their own chain. This means that there will be two separate blockchain, one belonging to bad miners and the other one which is the original blockchain I don't think “original” is the proper way to describe it. The chain with the most work is the correct chain, full stop. Once the bad miners succeed their attack, the rest of the nodes are forced to accept it as the consensus rules say so. About transactions, is it true that the number of confirmations is necessary for bitcoin not to be reversed? that 1 confirmation transactions can be reversed and be double spend by the bad miners? If the miners own a larger proportion than the 50% of the hash rate, then they can reverse any transaction, regardless of how many confirmations it has. I answered it few minutes ago: Re: Myth vs Facts and My Assumptions about Bitcoin. |
|
|
|
I remember about the 51% attack, can they cancel a transaction that already has 1 confirmation? Someone who owns 51% of the hashrate can reverse any transaction regardless of its confirmations, it'd just be a matter of time. They decide what's the correct chain. If they own less than that, then the more the confirmations the more difficult it becomes to catch up. This probability can be calculated using the C code displayed in the whitepaper: #include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
Where z is the blocks you expect to be found, q the probability for an attacker to solve those blocks and p the probability for the honest nodes to solve those blocks. Set the proportion of the hash rate and the confirmations accordingly to what you want, here: https://web.archive.org/web/20181231045818/https://people.xiph.org/~greg/attack_success.htmlHere's some noteworthy results: - With 30% of the hash rate, you have a ~62% chance to reverse a transaction with 1 confirmation.
- With 40% of the hash rate, you have a ~55% chance to reverse a transaction with 5 confirmation.
- With 20% of the hash rate, you have a ~10% chance to reverse a transaction with 3 confirmation.
Everything drops off exponentially as confirmations (z) increase. The 6 confirmations have the best security:speed ratio. It takes 1 hour, but even for someone who owns one third of the hash rate, it's improbable for their attack to succeed. (~21% chance) |
|
|
|
pooya87 = Pooh-yeahhhh-ate-seven [Southern accent]
WTF, poo-yeah? It's instant, ya! But, to avoid any misunderstandings, I address to the expert to tell us what do poo and ya stand for.  |
|
|
|
That's like an infinite regress isn't it? Because then C1 has to contain the hash of D and so on ad infinitum. This is exactly what I'm saying. You can't prevent double-spending without completing this endless scheme. The outputs of the final transaction, no matter when will they be, can be double-spent. The reference to B in A1 is secured by the signature in A so it cannot be modified. I don't disagree. A has a reference of B to A1. But, in order to have a reference to B, it means that B is an unsigned transaction, ready to be signed and broadcasted. But, in order to be signed, it needs to have a reference of C in B1, which means C must be an unsigned transaction, ready to be signed and broadcasted. In order for C be signed, it needs to have a reference of D in C1. It goes on and on, forever. |
|
|
|
L2 protocols are not ever going to have anything similar to PoW-type mining because they rely on the L1 layer. But, contributing power to a pool doesn't pay you on-chain without trusting the pool. I haven't tried this ever, but don't you get pool shares firstly and then you give those for BTC? Wouldn't it be better if you were rewarded every hour, off-chain? Also, let's not forget that: LN is essentially PoS!  |
|
|
|
I thought it was well known my name came from a random name generator. Wow, you're the first person I know who uses a random name generator. Could you PM me the generator you used? Do explain C'mon, “Loyce Vee” is the name of a cartoon character the most. Marcel is prestigious. Who's Crack? We are. We are all Crack Wright  so maybe I have to start addressing LoyceV as she from now on. Justified. Honestly, “Marcel”, a fox cycling with LoyceV as a username? Fun fact: When I was still a newbie I thought he was a female. That's the beauty of pseudonymity. |
|
|
|
Then, the owner of the coins can tweak the private key in the same way and make a signature that will be always unique for a given z-value. In order for the signature to be unique, you need to include into the previous output/transaction the z-value or use some sort of consensus rule in which z-value is calculated in a predictable way. For instance, when you created A1 you included B's hash into it. But, you must have stated what's the unique z-value that can be used in a signature to spend A1. But, for the B1 to be spendable by only one z-value, it means you must have also stated it somehow. Again, there's no point to dive into details if I don't get an answer to the following: A1 contains B's hash. In order to spend A1 I need to create a signature that involves B's hash, otherwise the transaction is invalid. But, in order to have B's hash I need to know which are the outputs of B, in this case just B1. But, B1 must contain C's hash. Is that correct until here?
|
|
|
|
Any idea what is going on? It was all a scam! My evil plan to make you look a bad poster! Or I was stupid enough to change the php version of blackhatcoiner.com ignoring that this will cause a problem to this service as the imagecreatefrompng function won't work properly. But, now that I re-upgraded to 7.4, it works like a charm. |
|
|
|
Technically you can, because you can create a consensus rule for R-value in a signature, so that for one public key, there will be only one valid signature for a given transaction. How? How can you ensure that from the [r, s] pair the r is valid only if it takes one value given a specific public key? The developer guide states that the secp256k1 signature is made using the ECDSA, a hash algorithm ECDSA stands for Elliptic Curve Digital Signature Algorithm. Not hash algorithm. Yes, there are hashes involved in the process, but it should not be confused with a hash function. But even if that enables the sender to generate two equally valid signatures for a given input, he still can't double spend because any other transaction will have a different payment address, and a different txid, which will not be referenced in the output that it's attempting to spend. A1 contains B's hash. In order to spend A1 I need to create a signature that involves B's hash, otherwise the transaction is invalid. But, in order to have B's hash I need to know which are the outputs of B, in this case just B1. But, B1 must contain C's hash. Is that correct until here? |
|
|
|
Or make it my full random name: Loyce Valenzuela Your real name is not Loyce? Okay, let's see. DannyHamilton is actually called Danny Hamilton, LoyceV is not called Loyce, but Marcel (which makes sense now that I rethought of it). What's next? o_e_l_e_o not called Leo? franky1 not from Frank? Satoshi not Craig? Don't do him short, it's clearly OO underscore EE underscore EL underscore EE underscore OO I removed the underscores and it's the worst thing I've ever seen in a sentence: oeleo. And I googled it. And there's a place by that name. Spooky coincidence or terrible irony for his privacy emphasis? |
|
|
|
There are at least two hashes in every transaction, the txid and the signature. The signature is not a hash. The txid is generated when it is still unspent and has no references to future transactions. The signature is generated after it is spent and has references. The transaction hash was calculated using the signed transaction and therefore, from a combination of the transaction itself and its signature. This means that the content of the signature cannot be changed if the transaction hash remains the same. If you choose to separate the transaction hash and the signature, for example by calculating the SHA256 only of the transaction without the signature, then you have another problem: You can't prevent the user from double-spending using two signatures. |
|
|
|
If you still think that double spends can happen in POV, just give me one example so I can fix it. An yet, you keep avoiding me... It's not necessary to keep generating new transactions forever, only when you spend them. A1 contains B's hash and it's spent. B1 contains C's hash and it's unspent. When I want to spend B1 I'll reveal C's hash which is a transaction that contains D's hash in C1. However, in order to know D's hash I need to also have E, since D1 contains E's hash. This never ends. Here's my pseudocode: TX A --> A1
|
> TX B (HASH) --> B1
|
> TX C (HASH) --> C1
|
> TX D (HASH)
.
.
.
Have I understood it correctly? |
|
|
|
Do you think this is better, or do you consider warpwallet with email+pw a bad idea in general? Email and password remind login credentials. Just leave a password text field which makes it look like a brain wallet. The safest option is none of those, though; it's to return you a seed phrase instead. Also, how can I verify these aren't sent to a server? Is the wallet open-source? |
|
|
|
Usernames = How I think * they should be pronounced [I apologize in advance]  Let me add more; - Hhampuz = Ham-pooz [Tone in H]
- o_e_l_e_o = o-ee-lee-o [Just like we pronounce Leo]
- gmaxwell - gee-max-well
- ETFBitcoin - E-Too-Foo-Bitcoin
- odolvlobo - od-o-le-vel-o-bo
- Welsh - Wέlsh
- LoyceV = Loy-se-Vu [French accent]
I know him as Loυ-chε-Vι. - mocacinno = Mocha!-seen!-NOOooooo [Japanese accent]
No way. It's mo-ka-tsi-no. |
|
|
|
I don't agree with you. So far, bitcoin clearly follows cyclicality, and as I have been saying since last year that this year will be bearish for the crypto market, I continue to say so. I neither agree with pooya one hundred percent, but I can't unsee this connection between the cycles and the halvings. Bitcoin's first four years were very significant. Half of the coins were brought into circulation. In the second halving, which occurred in summer of 2016, another 1/4 of the coins were included into circulation, leaving only 1/4 for the next halvings. In other words, if we assume the demand increases as times goes on, we should feel extremely bullish as it gains more scarcity. I guess this cycle is over, but I don't cross my arms. Again, nobody knows nothing. |
|
|
|
|
Show Posts
