Let me preface this with, I'm not exactly sure how bitcoind deals with receiving two equivalent blocks (two different block 213s for example). Obviously, once it receives a block 214 it'll keep the 213 referenced by its 214. But until then, from my research (which may be incomplete, but I can't find much about this) it seems that it keeps the block it received first. This, however, is a breach of the bitcoin protocol.

The bitcoin protocol specifies that in the case of a blockchain fork the winning chain is the one with the most work in it. Clearly, the first block received is not necessarily the one with the most work - the block with the most work would be the block with the lowest hash. For all neutral miners (miners who didn't mine either version block 213) and non-mining nodes, replacing a block is a normal occurrence that doesn't cost anything. Therefore, following the protocol and replacing the accepted block by the block with the lowest hash seems like an intuitive thing to do. It is also a useful thing to do - it immediately ends the current situation where it is more profitable to mine blocks with less transactions, unless the transactions pay a much higher fee than otherwise would not be necessary. I see no reason why bitcoin core does not follow one of the most basic rules of the protocol, especially when not following it has a cost in network utility.

Yes, I do know that Gavin's O(1) block propagation time solves the problem too, however these solutions can coexist. And implementing replace-by-lowest-hash would be extremely simple, compared to the O(1) propagation time solution.

EDIT:
To avoid bumping this, I'm just going to edit this post.
I disagree with some of Shorena's specifics, but I can't refute the general point which is that it would open up some possibilities for attack that currently aren't possible.

I suggest you read up on proof of stake. Bitcoin secures the network by proving that enough work (in the form of computing really low hash values) was put into generating a block that it would be (almost) impossible to have forged it. The proof-of-stake altcoins secure the network by proving that enough coin days were destroyed (I suggest you read up on what that means) in the process of generating a block that it would be (almost) impossible to have forged it. I have a much better understanding of how proof-of-work actually works than proof-of-stake, so I'm not really in a position to explain it better. But what I can tell you is that changing bitcoin over to proof-of-stake would be a huge change in the security model of the network. It would destroy some trust, and there's almost no chance it will happen without an extremely strong reason (stronger even than loss of some decentralization). The only way that could happen is if the current security model breaks somehow (51% attack, SHA-256 broken, etc), and even then other solutions would be considered first.

The reason not to implement something that is an incentive to keep bitcoin decentralized is that we don't know how to without either breaking trust in the network or adding an element of trust in a third party.

There is such a thing as a hybrid SSD HDD. I don't really know anything about it (so you should look into it yourself), but it seems to allow you to boot quickly from SSD while performing most of your everyday tasks on the cheaper hard drive.

Downloading the blockchain is easy. A much bigger resource hog is verifying the blockchain.

Updating isn't always important. The main benefits to updating are personal security and new features - occasionally there could be a network security update. If a full node operator isn't using the node to store bitcoin, they don't need to update for personal security, and they certainly don't need to update for the new features. They only need to update if there's a network security update or a fork, which is rare.

There is almost never a fork - it happened with version 8.0, but only because of a bug. Most versions of the bitcoin core client are compatible with the same bitcoin protocol.

EDIT - To clarify, bitcoin is a consensus driven network. A fork only happens if a fundamental rule of the network is changed. Most updates to bitcoind don't change the rules of the network, so they don't cause a fork - therefore running an older version doesn't break compatibility.

I suggest reading this wiki page:
https://en.bitcoin.it/wiki/Scalability

The 7 txps limit is arbitrary, not a design choice, and can be increased quickly if necessary.
Miners won't suffer from this - they only have to confirm each transaction once per pool.

That's subtly false.
Miners and full node owners are not the same. Though they both work for decentralization (as long as they don't own too much of the hash power / connectable full nodes) and the security of the network, the way they do so is completely different. See my comparison earlier. Someone can be both (as in your example - owner of full node with setgenerate=true), but someone definitely can be one without being the other.
One important distinction - miners are not required to include transactions in their block (read up on the O(1) block propagation discussion to see why this is important), so they are not required to do anything other than accept blocks from the network and push their blocks to the network. And since mining can be pooled, one copy of the blockchain can support many miners.

https://en.bitcoin.it/wiki/Scalability
Running a full node is much more than just computer switched on. It requires storing the entire blockchain (~20gb right now, but will scale as the network grows - and there certainly will be a financial price for all the hard drive space that'll take up once the it's growing fast enough). It requires accepting incoming connections, and accepting and sending on transactions to anyone who needs or wants to send them (8 mbps according to the above article assuming 2000 txps, which is certainly not free).
The article I linked claims that these problems are easily solvable as long as full nodes are running on high end servers. The price of a high end server is enough that most people won't pay that price just to support the bitcoin network.
The common resource we need to protect is not fees or block reward - that's reserved for specific people (miners). The common resource we need to protect is the security of the network (you know, the thing that gives bitcoin value).

There's only so much room for p2pools. If all 7000 (or however many there are) fullnodes currently in existence ran p2pools, only a few of them would have miners on them (and those would be the ones with the lowest fees, so they wouldn't even make too much money off of it).

That's not proof of fullnode, only proof of hash power. You can mine without being a full node as long as you have a full copy of the blockchain.

There are two separate problems here:
1) Figuring out a way for people to prove that they are a full node, that won't allow them to cheat (don't underestimate peoples' willingness to cheat when there's a financial incentive, or even just the ability to destabilize bitcoin involved).
2) Implementing this either (a) at the protocol level (where people who run full nodes are automatically rewarded with bitcoin) or (b) as an optional thing people can donate to if they so choose.

There will have to be a big debate over (2). There are a lot of merits and downsides to (2a), and it is definitely a useful debate. But until (1) is done, it doesn't even make sense to have that debate.
It seems that you created this thread to debate (2), but most of the discussion in this thread has centered around (1). That's probably because we don't have a practical solution to (1), so debating (2) isn't really practically necessary yet. Also, this is the Development and Technical Discussion board, so people here are more inclined to discuss the technical side of things than to debate the practical side of things.

The way communication over the bitcoin network works is, you send me a message then I send you another message.
While you can modify your bitcoin-qt code to send any me message you want to send, I will not respond with a message containing my private keys.
Unless you can find a bug in the bitcoin software that causes it to respond to some message with private keys (for example, the heartbleed bug in 0.9 - I might be misunderstanding what exactly is possible, but it was bad enough that 0.9 is insecure).

Centralized, and doesn't associate bitcoin addresses with nodes (only IP addresses).
It's fine for just getting a sense of the network, but not for trying to contribute financially to node operators.

The most important concept that people seem to be missing:
You can have a full copy of the blockchain and all unconfirmed transactions and not be a full node.
To be a full node, you also have to participate in relaying transactions and blocks, and accept incoming connections. If you use bitcoin core, and only have 8 or less connections, you're probably not a full node even if your block chain is up to date. And you are only a full node as long as you are accepting incoming connections, so you can be a full node for some hours of the day (when your computer is on, for instance) and not be a full node others.

You just need a full copy of the blockchain (and maybe unconfirmed transactions) to do this. See above. A full node owner can do it, but it's a niche and there won't be much room for competition in that niche.

No, see above.
Also, under that system a single full node operator could sign multiple addresses.

This only works if you can identify nodes (though,  allowing a full node to sign an arbitrary number of addresses is acceptable for giving higher priority to their transactions; node owners would have to show restraint and not abuse that, or miners would eventually start disregarding it).

Interesting. Proof-of-bandwidth. If you develop this idea further and write up a whitepaper, you might be able to get some support for developing an alt based on the concept. One issue I can see is that we don't want to ddos the entire internet (or even just the trans-oceanic pipes). Think of the implications of anyone being able to profit financially from sending junk data, and profiting more the more junk they send.

I agree that it would be complicated to implement, but bitcoin as a whole is complicated to implement. That didn't stop Satoshi from implementing it. I think this is a problem that will take Satoshi-level genius to solve securely. It's not currently a big enough problem to warrant it, but there are a lot of really smart people working on bitcoin. If the number of full nodes starts decreasing too much, the developers will find a solution.

Replace by fee without child pays for parent would make 0 transactions impossible to accept, as it would be trivial to double-spend back to yourself at any time before the transaction is included in a block.
Child pays for parent is useful, and poses no security risk; I really don't know why it isn't implemented.

This proposal does not change anything about the blockchain. To answer question 1, sort of. Since finding a block really just means finding a low enough hash to make the block valid, all the data except for the hash can be known to the entire network before the block is found.
Currently, when a miner finds a block, they have to send the entire block (all transactions in the block + header), to everyone else, which is harder the more transactions there are in the block.
The proposal is (oversimplified) to ensure each miner has all the transactions that will be included in the block beforehand. Then when a miner finds a block, they will only have to send the header and coinbase transaction (telling everyone who gets the block reward), and other miners will be able to reconstruct the block from this.
Since they will be able to reconstruct the block, the only difference is that the entire block isn't sent over the network.

Better question maybe...
What would you do if you setgenerate true and mined a block with 25 bitcoin after only a few seconds?
Then there's no moral obligation to send it back to anyone, because there's nobody to send it back to (unless you decide to distribute it evenly among everyone who has bitcoin, proportional to the amount they have, but I don't see the purpose in doing that).

So absolutely anyone who wants can become a criminal for absolutely no financial gain!
Remember, most physical goods stores have video cameras already to catch people who are shoplifting. Now we have a situation where for the potential scammer:
Risk:
- Guaranteed to lose the (small, but non-zero) extra money they paid (which can be increased slightly to account for this situation)
- Likely to become a criminal, and face a prison sentence
- Likely to be banned from the store for life, or at least have to wait around for one confirmation from then on whenever they go to the store
Reward:
- Small satisfaction that the store won't receive money

The number of people who would be willing to risk this is very small. Again, if the transaction is large enough that this happening occasionally poses an actual threat to the business, the business should be smart enough to make the customer wait for confirmations on either system.

EDIT: (late edit, but better late than never and there are no replies yet so it should be okay)
The advantage is as such:
Currently, accepting a 0 confirmation transaction runs the risk that a scammer will create a transaction (via software remember) paying a utxo to themselves, and another paying it to a merchant's address. They have some direct connection to the merchant - I don't know how they acquired this, but they have it (yes, that is possible if they can find the merchant's IP, which depending on the merchant might not be difficult). But the merchant and the scammer also have other direct connections. So the scammer simultaneously sends the transaction paying a utxo to the merchant, and the transaction paying it to themselves to all their other connections (with their software, not trying to manually click two buttons at once obviously). This gives them an advantage in network propagation, and the merchant sees the valid transaction. The merchant releases the items, and the scammer leaves; later the scammer's transaction is much more likely to end up in a block. This possibility makes it very risky to allow anyone to leave until their transaction has at least one confirmation.
With replace-by-fee and child-pays-for-parent, in the normal case, the merchant would immediately (via software, not manually) send a child transaction paying the temporary fee back to the customer. These would be confirmed in the same block in almost all cases, and the customer would never be without access to the temporary fee. The customer's software would pay this extra fee for them; the customer does not have to know about the fee at all (as long as they have enough bitcoin to cover it; if not they can stay around for a confirmation). The merchant's software would send the fee back for them; the merchant does not have to know about the fee at all. In the case of an attack as described above, the merchant's software would automatically send the scorched-earth transaction, costing the scammer his temporary fee and the entire balance of the transaction. Since almost nobody will be willing to pay just to screw a merchant out of a small amount of money, this is unlikely to happen and the merchant can allow the customer to leave immediately.

This  is perfectly normal behavior. The change from each new transaction is unconfirmed until that transaction is included in a block.

EDIT - If you're wondering what I mean by change, read this:
https://en.bitcoin.it/wiki/Change

I'm not advocating anything that would force anyone into paying for full nodes. But some people would like to donate to full node operators, and I would like it to be possible to do that with full faith that you are actually donating to a full node operator. It simply is not right now.
As for coinjoin nodes, that's a separate topic, and it may or may not be implemented (regardless of our advocating for or against it in this thread).

That's what I was referring to, yes.


The percentages did indeed come out of thin air. I was assuming that the scammer can send directly to the sender and at the same time to everyone else. Right now, if I understand the system correctly (and depending on the wallet of course), the victim keeps his version of the transaction in his memory pool while sending it, and rejects the double-spend until it gets included in a block.
And the scammer doesn't need to do this manually - he can have software do it for him.

Yes.


I did forget about jdillon's solution. Assuming it takes 13 seconds for a transaction to propagate through the network, and a block is found once every ten minutes (600 seconds), there's less than a 13/600 chance (oversimplified, but you get the idea) of a double spend getting into a block before the victim sees it, then another less than 13/600 chance of the transaction being included in a block before the scorched earth transaction is seen (if the scammer has a miner friend then all bets are off anyway remember). The merchant doesn't need to do any of this manually; their software will do it for them. So you need to overpay by 13/300, or about 4.33%. If 4.33% is a significant amount when I'm getting it back later, you bet I'm waiting for confirmations anyway if I'm receiving the money. Hopefully, merchants will offer the choice of temporarily pay 4.33% or stay around for a confirmation, then I can make the choice depending on the size of the transaction. And if the merchant steals 4.33% on a small transaction, they'll cost themselves more in trust than they gain in the transaction.

As for the transition period, you can't be afraid to implement improvements because it will temporarily make life difficult. You'll never improve anything that way. The bitcoin community has shown itself to be fast to upgrade when it's important.
EDIT - The very thread you linked shows a case where 0 confirmation transactions were temporarily insecure because of an upgrade.

Good luck getting an invite tomorrow.

Fair, though I know I just run fullnodes on computers or servers I have anyway, as a thing it does on the side.
That honestly sounds like a bigger problem than a 51% attack, since it would be easier.