|
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
(X) Users of email will not put up with it
(X) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
(X) Requires immediate total cooperation from everybody at once
(X) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
(X) Unpopularity of weird new taxes
(X) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
(X) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
(X) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
(X) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(X) Countermeasures must work if phased in gradually
(X) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
|
|
|
|
This. When (or more likely) if ECC is compromised the most likely scenario (based on prior crypto attacks) it likely will be a partial compromise. That is private keys must be brute forced but can be done so millions or maybe even billions of times faster. That means that the day 0 threat to Bitcoin will be minimal. The network will operate for a while with "legacy" addresses and new "strong" addresses.
In time though those legacy addresses will represent a risk. A method to sunset that risk may need to be devised. Even then it will be controversial and require some thought. To change the protocol today in such a fundamental manner is just asinine.
A weakness, unlike a clean break, would automatically provide the sunset. No action needed. |
|
|
|
Yes, a 51% miner effectively has 100%. That is correct. That is why 51% is twice as profitable as 49%. Actually, more than twice as profitable in the medium to long-term, but I won't go into the details here. That is why it makes sense to perform a massive centralized investment like this to get 51%. Once you have it, you get all the coins and everyone else gives up. Winner take none.
Cunicula, don't take this the wrong way, but could you please shut the fuck up, or maybe even go die in a fire or something like that? Not every thread on these forums exists for you to go trolling in. |
|
|
|
|
GPUs are already produced in pretty much top of the line fabs. These custom ASICs will certainly not beat them in feature size or clock speed. So, where is the waste that will be cut to achieve 100x or 1000x improvements? Surely the PCIe interface and cache don't account for 99% to 99.9% of the real estate of the GPUs we use now. Is there enough cruft in the ALUs that can be cut?
|
|
|
|
This currency is designed to work fine even if 90-99.9999999999999999999999999999999% of coins are lost.
Fixed that for you. If every single BTC already mined was lost today, the currency would still work just fine. In 200 years, long after the subsidy was done, even if only a single satoshi remained, the currency would still work. Bitcoin uses a scaled integer representation. We can change the scale factor to renormalize, if needed. We will almost certainly do it to match future CPUs many decades before we need to do it for economic reasons. |
|
|
|
A decreasing bitcoin supply lends to price instability, because there will be a greater oscillation between the market thinking the supply is too deflationary to promote a large bitcoin economy, and the market thinking bitcoin value will skyrocket due to growing usage and decreasing supply.
It also creates more uncertainty as a larger percentage of the bitcoin supply goes off-line, with a possibility, but not a certainty, that a large amount come back into use suddenly when someone discovers an old wallet.
Re-issuing lost coins improves bitcoin's security at a time when block rewards will be much lower, and it will do so without inflating the bitcoin supply. With lost coins, either present bitcoin holders can be rewarded with deflation, or people who mine bitcoins can be rewarded for contributing to network security with bitcoins.
The latter can actually increase the value of bitcoin more then rewarding bitcoin holders with deflation, for the three reasons mentioned.
Oh God, not this post again. Can you people please try to understand that saying something doesn't make it true? |
|
|
|
The issue would be invalid nodes will build a block with the bad tx. It will be orphaned and the invalid nodes will see the same bad tx as a pending tx and perpetually make new bad blocks with the same bad tx. Any out of date bitcoind will see these bad blocks as good and having the highest height and try to build off it.
New nodes will see the bad block as invalid and build off the prior block thus never get invalidated when the bad chain becomes orphaned.
I am not saying that mystery IS using an outdated bitcoind but outdated nodes will perpetually try to include the bad tx in the next block.
The 35 orphaned blocks are not a long 35 block chain they are a large number of 1,2,3 block chains.
But the old miners are only a small fraction of the network, and they consider the live chain to be valid too, so they will only be working on invalid blocks for a small fraction of the time. While 100% of the blocks generated on that fork will be orphaned, most of the time their current block will be the same as our current block, because our chain keeps winning because we have much more hashing power. So, even if the 0-tx miner was using an old node for his prevHash, that old node would be right most of the time, and most of his blocks would still be fine. Although he seems to have disappeared, P2SH doesn't get the credit. Something else does. |
|
|
|
Except that he wasn't including any transactions, so he wouldn't include the poison transaction or any that depend on it.
But if his bitcoind is out of date he would see the invalid block as valid and continue to build upon that making any block he generates invalid (tx or not). A block built on an invalid block is by definition invalid. But the majority of the network would overrule him and even his broken node would have the correct current latest hash most of the time. He would need to be using a node that not only is still accepting invalid blocks, but is only accepting invalid blocks. I don't think that the recent changes have orphaned any old versions; my old 0.4.0 node is still going strong. Also, the graphs don't show a sharp transition on the 1st. Does anyone know when the first orphan fork happened? |
|
|
|
I don't understand the broken-ness well enough to explain it, but the smarter-than-me developers in bitcoin-dev said the script is invalid in some subtle way that the current bitcoin versions recognize and reject and that old bitcoin versions don't recognize and think is valid.
Sounds to me that this transaction was intentionally created to put MM out of business for a while and to do exactly what it is doing to miners who didn't upgrade. Except that he wasn't including any transactions, so he wouldn't include the poison transaction or any that depend on it. |
|
|
|
and do you realize that my attack simply involves making a second transaction, which for all intents and purposes is identical to a normal transaction? until there's a way to prevent the attack, i don't see any point in discussing merchant adoption of an insecure system.
grue, I understand that your attack has relevance to standard smart cards. How much relevance, I'm not sure, since those basically require you to trust the POS terminal regardless. But I want you to look again at the hardware I'm proposing be used, and to think about the process flow: - The terminal sends the transaction amount to the smart card.
- The transaction amount is displayed on the smart card.
- The user presses the button on the smart card to verify the amount.
- The smart card creates and signs the transaction.
There is no way to create multiple transactions without consent. There is no way to create transactions with the wrong amount without consent. No sensitive information is transferred to the terminal. All transactions are created on the card itself using Bitcoin keys that never leave the card. This is a good model for a hardware wallet. It is essentially the same model as the "box with serial port" model that has been discussed in many other threads. My only objection is that I think that smartcards are a lousy choice for this model. But, in parts of the world where smart card terminals are common, the network effect may very well be more important. |
|
|
|
|
Is your block chain current?
|
|
|
|
grue, do you understand that the entire point of a smart card is that the private key never leaves the card? Basically, the POS terminal just sends the balance due to your card, which displays it for you. You then press the button to verify, and the card creates the transaction and signs it. No need to trust anything.
This is what I have proposed. If you'd like to discuss any flaws you see in what I have proposed, I'd love to hear them. This is exactly right. The card must sign the transaction itself, and it must do so only after showing the transaction to the user and getting confirmation. But the details are tricky. |
|
|
|
Think more along the lines of a small custom device with a screen, a couple of buttons, and a serial port (or serial over USB, or serial over bluetooth, or serial over NFC, etc). The programming interface, if it has one, must be internal, or it must load software from a memory card (like SD).
What about SIM cards? I wouldn't trust a device without a display and keypad (or at least a pair of buttons!) built-in. I also dislike the idea of a device just signing a transaction presented to it, rather than generating the entire transaction internally. But, this can be overcome. Also, in my opinion, the device must generate all keys after it enters my exclusive possession, and it must include a genuine entropy source. This may be extra paranoid on my part, but I'm not sure I even like the idea of importing keys into the device. |
|
|
|
With the availability of merged mining, Bitcoin could be optionally replaced using scripts that are impossible to eval-true
Mmmh. How do you plan to algorithmically 'prove' that a script is impossible to eval-true ? OP_PUSHDATA(20) <Bitcoin2Address> OP_PUSHDATA(8 ) BITCOIN2 OP_FALSE OP_VERIFYI already did. The second-to-last op-code is OP_FALSE which pushes "false" onto the stack, and the OP_VERIFY makes sure the top-value of the stack is "true", else the script fails. Since this script always runs last, there's nothing any one can do to avoid having OP_FALSE OP_VERIFY at the end. Sure, there are specific instances of script for which you will algorithmically be able to prove what you want. My question was more general: given an arbitrary script, how do you plan to prove that it can't eval to true ? Other than hard coding a list of template matches ? He's not talking about a general case. He is saying that if we ever need to transition, we could do it by sending to this specific template. They would be provably dead on the old network, and in a way that the new network can recognize. |
|
|
|
I don't understand the goal. What problem with bitcoin are you trying to correct?
No particular problem. I'm making a hypothetical assumption that Bitcoin 1.0 has insurmountable problems that will lead to security and integrity issues, and that somehow enough support was available to consider moving to something better. There's a lot of lessons learned (such as on the Hardfork Wishlist), and it may be in Bitcoin's interest to try to move to something better without throwing everything away and starting over (screwing over everyone who already has BTC). It would be an extraordinary hurdle to migrate the community of staunch Bitcoin 1.0 followers, no matter what the justification is. I feel like people would ignore all reasonable warnings about imminent doom and ride the train right into the Bitcoin apocalypse. But perhaps there's a way to produce a smooth migration scheme that allows users to migrate at their own pace, but still preserve the existing supply curve and wealth distribution. To follow up on severability: I suppose if there was enough support, the main BTC software could be updated to "stop" at block 1,000,000, and then all unspent outputs at that block become generation inputs on BTC2. Then generation would continue as normal on BTC2. Yes, complicated.... I don't think my idea is really feasible, and even if it was, how much different could BTC2 actually be, given being tied to the BTC1 generation scheme. But I think it's a useful exercise to know if such a migration was possible. I think it much more likely that components will be swapped in and out of the bitcoin framework, rather than needing to start over. A problem with ECDSA, RIPEMD-160 or SHA256 would cause a migration away from those functions to secure replacements, but nothing that would require a new chain. Think more like "Blocks after 1,000,000 MAY use SHA3 instead of SHA2 for the header has, and blocks after 1,200,000 MUST use SHA3" and "Transactions in blocks after 750,000 MAY use NewfangledDSA instead of ECDSA" etc. |
|
|
|
I don't like to ruin it for you guys but what's going to prevent me from shopping a message & timestamp onto some random picture floating around the web?
Presumably only idiots will send money to a shooped address. That's why it should be written on the body or in her own handwriting. So I'd just have to practice my layermask technique and my *girly* handwriting then? I don't see the problem. |
|
|
|
|
Finally got it after 31 hours. I was starting to get worried.
|
|
|
|
I wonder how much thought Satoshi gave this and what his main reason was. I think it was kind of a fairness thing. Whatever it was I think this decision more than most involved his guessing about how (time line etc) Bitcoin would be adopted.
Satoshi's choice of integer representation is obvious enough, but I think that the choice of right shift for the subsidy was deliberate too. It is exact and unambiguous right down to the final unit. Thanks for pointing this out. It may not be obvious to those with no experience in binary numbers. In fact, I haven't even thought about it that way. Is there any links available to how that code was "hashed" out among the developers? It would sure be interesting to see what their discussions were when they finalized it. There choice definitely makes for a very small piece of slick code to handle block rewards. A right shift in the binary representation of the number 50 every 210000 blocks. Presto! That tells me their decision was based almost entirely on getting it coded quick and keeping it simple - there were bigger fish to fry at the time. And it was just an experiment... I don't think they really envisioned it would be where it is today. Kudos to them for their achievements. Bitcoin uses a scaled integer representation. The subsidy is 5,000,000,000 satoshis, or 1001010100000010111110010000000000 in binary. We scale that by 100,000,000 when we show things to the user, and we call 100 million units to be 1 bitcoin. Pay attention that this is not similar to fixed point. The pre-scaled value (5 billion) is what gets shifted, not the post-scaled value (50.00000000). In 33 years, the 9th shift will result in the subsidy being cut by slightly more than half for the first time. (Or is it the 10th shift in 37 years? Bah. Not going to count the zeros again.) Every binary machine will always get this subsidy calculation right, because right-shift-without-carry is one of the simplest operations in the binary world. Every other scheme will have to figure out how to deal with inexact operations and rounding one way or another. This BIP does call for more complex code (but not impossible) for the rewards to be handled as proposed. I've tried to stay away from the details of code implementation in the BIP because it just opens another can of worms for everyone to argue over which seems pointless until it reaches mass consensus.
However, since you bring it up... do you have an idea how hard it would be for the average developer to come up with an implementation like this? Just curious.
My opinion, is it would only take a few days, but could get take longer if there's a difference of opinion between developers (i.e. BIP16 vs. BIP 17).
Well, it can't be implemented at all, as written. To implement it, someone would have to answer the questions that I asked back in post 38. If you don't care how the rounding gets handled, then yeah, I should think a couple of days should suffice, if even that long. Actually, shit. I just realized something. If the subsidy drops by 0.000031746 % on every block, before long, you are going to need to calculate something like .999999968254^200000, which is going to be painful. But, I guess we could cheat by embedding the current subsidy in the block or something, so that each node only has to calculate the next subsidy. |
|
|
|
|
I've tried to follow this thread, but it meanders a bit.
Is the basic idea under discussion having a wallet-only client running in a small hardware device that can interact with POS terminals?
Most of the smartcards that I've seen are just (tiny) general purpose CPUs embedded in a card, usually with a small ROM containing a secret key. This is not a useful model for bitcoin. For bitcoin, you need the secrets in RAM (flash, etc) because you need to be able to add new secrets. You also need to make sure that you don't ever let the device communicate with a hostile device using the same physical pins that can be used to reprogram or dump it.
Think more along the lines of a small custom device with a screen, a couple of buttons, and a serial port (or serial over USB, or serial over bluetooth, or serial over NFC, etc). The programming interface, if it has one, must be internal, or it must load software from a memory card (like SD).
|
|
|
|
I wonder how much thought Satoshi gave this and what his main reason was. I think it was kind of a fairness thing. Whatever it was I think this decision more than most involved his guessing about how (time line etc) Bitcoin would be adopted.
Satoshi's choice of integer representation is obvious enough, but I think that the choice of right shift for the subsidy was deliberate too. It is exact and unambiguous right down to the final unit. |
|
|
|
|
Show Posts
