|
Xanax is almost certainly an alt of Zombie. I'll release his IPs if he doesn't start sending refunds within a few days.
|
|
|
|
|
Couldn't "dumb" miners get all of the necessary data fairly easily and without doing any verification by downloading the latest block and getting the necessary transactions from Bitcoin nodes (with getdata)?
|
|
|
|
Then Haplo's clarification is correct?
I think so. So it means instead of forcing miners to include transactions, they would instead be forced to access recent blocks and extract data from them.
What's still a little confusing about that on a conceptual level is this: mining ALREADY requires access to recent blockchain data, in the form of a hash of the prior block. Even if it required new code, couldn't the method already being used to distribute that prior-block-hash to all the nodes on a botnet be copied/modified to also distribute the newly-required "proof of verification?"
It's not just recent blocks: they'd need to be able to access random unspent transactions in the chain. The proof of verification could be distributed, but then at least you know that someone is doing the proper verification and miners aren't blindly building onto invalid blocks. |
|
|
|
But he can't. If the majority of miners include 10 free tx on the required list then "mystery" (or any miner or pool) is required to include them or have that block invalidated by other miners. He can't even exclude free tx without taking a risk his block will be orphaned.
You're talking about the "discouragement" proposal. I am not. Discouraging blocks should be a last-resort tool. The incentives are wrong: building onto a discouraged block has no extra cost for miners, but discouraging a block has significant extra costs. |
|
|
|
And then, miners get to choose which list to use. So why wouldn't a miner just publish his own list, then immediately use it?
Regular miners wouldn't use these lists at all. They can do whatever they want. The lists are meant to stop "dumb" miners that can't verify the chain for themselves from just blindly building onto the longest chain. This proposal makes all miners verify the chain or get someone else to do it. If this "mystery miner" is already verifying the chain properly, then there's no problem: he can set fees to whatever he wants. |
|
|
|
Are gambling ads ok?  Yes. |
|
|
|
|
Current state:
Slots BTC Person
1 3.5 Goat
1 3 Goat
1 2 NothinG
4 1 cablepair
1 0.5 c0ffer
|
|
|
|
The 49% may solve a block BUT that block will be ignored by the miners in camp "A".
That's not the current behavior, and that behavior is not part of gmaxwell's proposal. Blocks won't get rejected/discouraged for not including transactions. All blocks just need to include an extra "proof of validation". |
|
|
|
Whatever list is used by 51% of miners will orphan out any other chain.
Why? |
|
|
|
|
You're misunderstanding the proposal. Anyone who is verifying the chain can publish a list. Lists can use any fee rules. For example, Bitcoin Block Explorer might publish lists at /q/getValidationProof/minFee, which would only list transactions with a fee above minFee. Under this system, dumb miners would be able to choose essentially arbitrary fee policies; they'd just be forced into mining only properly-verified transactions and blocks.
|
|
|
|
When there are conflicting lists?  The miner could choose the list to use. Someone could even publish valid lists that are always empty, though rational miners won't use these because including a transaction is almost free. |
|
|
|
Specified by whom? The person who solved the last block? If so why aren't the transactions in their block?
Anyone could publish lists of transactions that should be included in the next block along with the necessary "verification proof". Bitcoin nodes themselves could publish lists using a new network message. |
|
|
|
A I understand it (possibly wrong) your solution is that miner must include in the block a hash of the tx of the prior block. The issue is that doesn't accomplish anything. A few distributed servers (or nodes, or calls to blockchain.info) could provide that data via remote call. A miner could easily then have nodes process blank blocks with valid signatures.
Under gmaxwell's proposal, the miner would need to include exactly the transactions specified by the person who verified that the transactions and the previous block were valid. So if blockchain.info published a set of 10 verified transactions, the miner would have to include all 10 of them. Satoshi intended an open fee market. If I feel my computing time is worth 1 BTC per fee that is my right as a miner.
If necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about. A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in. I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.
|
|
|
|
But with Tor you have to rely on a certain number of output nodes which could be blocked or monitored?
Tor currently has more exit nodes than I2P has nodes, and I2P doesn't have anything like bridge nodes yet, so I2P would be much easier to block. Sure, the US government could block Tor pretty easily, but they could block I2P even more easily. (I do think that the design of I2P is somewhat better than the design of Tor.) It's not necessary to have a totally new I2P Bitcoin network, since just a few peers can link the two branches of the Bitcoin network without creating extra risk or anonymity concerns for other I2P-Bitcoin users. This is unlike the I2P-only Gnutella and Bittorrent networks where there's too much data for just a few links to keep the network working (or not in a scalable way, at least). |
|
|
|
|
That wouldn't be much better than using Bitcoin with Tor, since the problem with Bitcoin anonymity is mostly due to the way Bitcoin transactions work. Anonymity at the network layer isn't the main problem.
|
|
|
|
|
Topics by people you've ignored are now shown in grey.
This only applies to the default theme, and it's not visible on search pages, "show unread posts...", or "show new replies...". I could extend it to those pages if necessary.
|
|
|
|
0.5.3.1 was signed by at least four of the top Bitcoin developers. It'd be very difficult for an attacker to get these signatures on a trojan. |
|
|
|
|
New VIP donator: cryptoxchange. Thanks!
|
|
|
|
0.3.15 must have a lot of security issues by now...
Probably a lot of DoS stuff, but I -connect directly to a trusted node, so that doesn't matter so much. I don't know of any other serious security bugs. |
|
|
|
|
The only GUI version of Bitcoin I use is 0.3.15 because I usually don't need the features in the newer versions, and AFAIK none of the security problems apply to me. Maybe I'll upgrade if I ever have to download the blockchain from 0 again.
For a long time I used 0.3.19.2 for all of my bitcoind installations, but I needed the faster blockchain downloading and sendmany, so I'm now using the latest 0.5.x version.
|
|
|
|
|
Show Posts
