https://en.wikipedia.org/wiki/Fork_(software_development)

It would be the equivalent of creating a new cryptocurrency, whose chain is identical to Bitcoin's blockchain up to a certain point (the fork point). From that point on, they're different currencies.

This would happen if the new cryptocurrency has rules which make it incompatible with Bitcoin. For ex, when the block reward halvened, some people had the intention to fork bitcoin and create a cryptocurrency that would always give 50 BTC of inflation per new block. AFAIK they've abandoned the idea.

Anuncie em sites tipo esse: https://www.bitmit.net/ pra ter mais visibilidade.

Fotos são sempre úteis também pra vender um imóvel.

This is a scam, but just so it's known, women in authoritarian regimes which forbid abortion can always order abortion meds from the Women on Web: https://www.womenonweb.org/

This a Dutch organization, I believe it's the same which once had a boat that would go around the shores of such nations, pick women wanting an abortion and make the procedure on international waters.

Btw... they should accept bitcoins, since what they do requires privacy...

Yes, they are. The corresponding private key will never be found, as that would be the equivalent of brute forcing it.
Unless, of course, some critical flaw is found in the algorithms used by BTC that would allow for a private key to be found without having to brute force it. That's not something you should be afraid of.

Come on, it's safer than that. To pull off a double-spend, you need some technical expertise, and perhaps the help of a miner. While Mr Everybody can easily break a promise, I wouldn't say he can make a double-spend.

But yeah, you're right that if you have no way to go after your customer or interrupt the service, you probably shouldn't be accepting unconfirmed transactions.


Software can/should be clever enough to detect such a thing.

IIRC, bitcoind has soft (bitcoind's) and hard (Bitcoin protocol) limits for that. Meaning that it will not spend nor build a block spending coinbase less than 120 blocks old, but it will accept a block which spends it a bit earlier (100 blocks I believe, not sure).

Seriously?
Sending money to a company whose sole purpose is to sell Bitcoins is already "proof beyond reasonable doubts" that you're buying bitcoins.

Come on. I haven't read the entire topic yet, but are you seriously implying that his service has any amount of guilt in this? That OP has something to "solve"?

People should simply learn not to send money to unknown types on the internet without escrow. Either you verify the other party reputation or you use a reputable third party, specially for meaningful amounts.

Financial privacy should not be thrown away simply because some are irresponsible with their money.

That said, I don't doubt at all that he might be required by law not to respect people's privacy, as you say. If that's the case he doesn't have much choice anyway.


They're already sending money to BitcoinNordic account anyway. Unless you're talking about owners of joint accounts who don't want the other owner to know where the money is going to (fishy), for everything else that matters it's already "written" in their statement what they used that money for.

Yes, and for the second question: http://research.stlouisfed.org/fred2/series/EXCRESNS

Mostly because banks are holding most of the extra money as excess reserves. Also, prices are not such a direct/immediate linear function of money supply, although they're strongly related.

hahaha, Krugman makes fun of himself alone, we don't need to say anything. I don't know which is worse, this or the alien invasion to boost the economy thing.
The sad part is seeing people still taking this moron seriously.


As a matter of fact, that's kind of how it works out:  https://mises.org/daily/4029

Taxis != public transportation.
I'd say that the majority of people who get a taxi do have a vehicle, they just do not have access to them in that moment (or do not want to, like when they're drunk etc).

Nice, so GetBlockTemplate gives the worker some decision power over the block contents, allowing him to change some details every time the nonce overflows. And as a bonus, it allows workers to be sure they're not working on something "evil" or against their interests. A decision-power decentralization in centralized pooled mining. Neat solution.

Thanks kjj.

Well, you must admit that they have a little bias: they can all read C++ fluently. Such a documentation would be useful precisely for those who can't. But Armory guy makes a good point:


Maybe simply not calling it "specification" would be enough to avoid most problems raised here.

Juste par curiosité, as-tu choisi vraiment le client lourd (qui fait cette synchronisation), ou simplement tu ne savais pas qu'il y a des alternatives qui n'ont pas besoin de passer par là?

J'ai l’impression que beaucoup de monde télécharge bitcoin-qt sans se rendre compte des alternatives, car elles ne sont pas très explicites sur bitcoin.org.

This.
If you really want such specification, DIY or offer a bounty to someone else.

I understand that. My doubt concerned classic transactions (what existed before P2SH), in which - I thought - the script was defined by the sender.

Apparently, according to Pieter Wuille, it was always the recipient that specified the script via the receiving address. So I'm imagining the only change brought by P2SH was to hash the script portion in the address, making it constant-sized, is that the case?

EDIT: I don't see where the script enters in the steps described here though... It only comments this

So I suppose there are different algorithms for the production (and parsing) of an address, the one described on that page only concerns "classic addresses".

Thank you,


But, if that's the case, what was the point of that pay-to-script-hash development? If the address always contained the script, since the beginning of Bitcoin times, what did that development add?

Was it because the script was not hashed in the address, so the longer it was, the longer the address would be? The whole point was to have constant-sized addresses?

Ok, I just read about the extraNonce field on the wiki. That's what's changed when the nonce overflows.

Do workers have their hands on this extraNonce?

EDIT:

Just found this:


Allowing the worker to manipulate the timestamp might help, but if the timestamp is in seconds, I'm afraid that might not be enough. According to this page, BFL claims its MiniRig will be capable of calculating 1,5*10¹² h/s. Rounding 1000 to 1024 (2¹⁰), that would make something close to 1,5*2⁴⁰ h/s. It would overflow the nonce 256 times per second! (if I haven't made any mistakes on these powers there)

It's true that if the worker can change the timestamp every second, it only needs to request the amount of work it's capable of processing in one full second. For the next second, it can change the timestamp and repeat everything again...
Or is the timestamp in milliseconds?

Anyway, how will (have?) people solve(d) this?

Please correct me on what I"m wrong.

AFAICT, a mining pool assembles a block, generate its header, and give the header to its workers. The workers will try to calculate a hash for that header that beats the current share difficulty by changing the value of the nonce. Whenever the nonce is exhausted, they attempt a different block. Pools may change the block header as much as they like simply by generating a new address for coinbase, they don't depend on waiting for new transactions nor rearranging them.

The nonce is only 32 bits long. We can assume that ASIC devices will be able to calculate 2³² hashes very quickly.

Wouldn't that mean too much upload bandwith will be required from pools? Not to mention the capacity to generate lots of different headers quite fast.

I confess I'm quite ignorant on mining since I don't mine myself, so it's quite possible that this problem is already solved, and I'm not aware about it.

For example, do pools allow their workers to change the header themselves, by rearranging part of the transactions for example? That would increase the size of individual messages sent because at least some transactions plus Merkle branches would need to be sent back and forth, but it could certainly decrease the frequency that the worker needs to get new work from the pool. It could decrease the required bandwidth after all...

I was discussing Bitcoin with some geek colleagues today during lunch, and one made a question to which I'd like to verify the answer.

He asked what would happen if somebody send some coins to an address A which I control, but the script to spend this output cannot be executed by me, so I can't actually spend that money (he was trying to imagine a scam in which you claim to have made a payment, the receiver verifies the payment, but then with the use of script you send the money back to yourself).

I answered that what would probably happen is that bitcoind (and I hope every other client) would not consider that the money is in your wallet. If you're not capable of spending it, it's not yours, even if your address is in the outputs of the tx.

That's correct... right?

Can I assume that every time that my client does not immediately recognizes the script that was attached to the output, it considers that the money is not mine, even if the script in question actually allows me to spend that money? (imagine it's a any-of-2 multisig, for instance)?

Thanks.