Would the idea then be to make a share chain that is invalid if it contains two transactions spending the same output? So that in order for the miner to include a double spend, he would have to discard the shares that include the original transaction? That could be a problem with 1-second blocks though...
Interesting. That solves the political problem with the idea that individual P2Pool miners would be forced into including certain transactions. Instead of being forced to include certain transactions, they just wouldn't be able to include one that conflicts with past blocks on the sharechain.
Topic: BIP Draft - Instant Partial Confirmation - page 2. (Read 4476 times)
Would the idea then be to make a share chain that is invalid if it contains two transactions spending the same output? So that in order for the miner to include a double spend, he would have to discard the shares that include the original transaction? That could be a problem with 1-second blocks though...
Interesting. That solves the political problem with the idea that individual P2Pool miners would be forced into including certain transactions. Instead of being forced to include certain transactions, they just wouldn't be able to include one that conflicts with past blocks on the sharechain. I believe it has been touched upon somewhat already, but what about if - instead of having to trust miners to include a transaction into a block - the client is sent blocks that have difficulty of 1/600th of the Bitcoin block chain's difficulty? This would produce, on average, one block (with 1/600th the difficulty of the block chain) every one second (provided all the miners participate).
It's not a guarantee because the inclusion isn't fixed like it its when a transaction is actually mined, a miner could stop at any point. Perhaps you could imagine some kind of system for discouraging that, but it would need a consensus mechanism... and would have to force all miners to mine the same txns (or at least no conflicts)Would the idea then be to make a share chain that is invalid if it contains two transactions spending the same output? So that in order for the miner to include a double spend, he would have to discard the shares that include the original transaction? That could be a problem with 1-second blocks though...
I believe it has been touched upon somewhat already, but what about if - instead of having to trust miners to include a transaction into a block - the client is sent blocks that have difficulty of 1/600th of the Bitcoin block chain's difficulty? This would produce, on average, one block (with 1/600th the difficulty of the block chain) every one second (provided all the miners participate).
It's not a guarantee because the inclusion isn't fixed like it its when a transaction is actually mined, a miner could stop at any point. Perhaps you could imagine some kind of system for discouraging that, but it would need a consensus mechanism... and would have to force all miners to mine the same txns (or at least no conflicts)P2Pool now does this— miners exposing what they're working on in p2pool shares with no enforcement— however.
I believe it has been touched upon somewhat already, but what about if - instead of having to trust miners to include a transaction into a block - the client is sent blocks that have difficulty of 1/600th of the Bitcoin block chain's difficulty? This would produce, on average, one block (with 1/600th the difficulty of the block chain) every one second (provided all the miners participate). The receiver can actually check that the miner is working on his transaction if the miner creates a hash tree of all the transactions in the block he's mining, and then sends the client the necessary leaf hashes to verify that. The miner would only have to send 2*log2(num_tx)-1 hashes from the hash tree to the client in order for the client to verify that his transaction is being mined on in a block. This is an implicit guarantee that the client's transaction is not a double spend, as the miner's block wouldn't get accepted if it contained a double spend.
So if we let the data blocks in this example be transactions, and the client's transaction be "Data block 000", the miner would only have to send "Hash 0-0-1", "Hash 0-0", "Hash 0-1", "Hash 0" and "Hash 1" in order for the client to verify that his transaction is being worked on (since "Top hash" is included in the block header and the client knows the hash of his own transaction ("Hash 0-0-0").
Does anyone have any information on how much data a P2P network specializing in forwarding these types of messages would be able to handle? Only the block header would need to be sent out every 1 second (assuming all miners participate). When new transactions are sent into the network, that some client wishes to secure against a double spend, a hash of this transaction should be spread around in the network, so that clients can confirm that their transaction is included in the block. Perhaps the system should include some way for clients to advertise which leaf hashes they need in order to confirm that their own transaction is included in the block. Ie., if I'm concerned about the two transactions "Data block 003" and "Data block 006" being double spent, I wouldn't need to be sent "0-0-0", "0-0-1", "1-0-0" and "1-0-1" as they are not needed for me to verify that my transactions fit into the hash tree.
So if we let the data blocks in this example be transactions, and the client's transaction be "Data block 000", the miner would only have to send "Hash 0-0-1", "Hash 0-0", "Hash 0-1", "Hash 0" and "Hash 1" in order for the client to verify that his transaction is being worked on (since "Top hash" is included in the block header and the client knows the hash of his own transaction ("Hash 0-0-0").
Does anyone have any information on how much data a P2P network specializing in forwarding these types of messages would be able to handle? Only the block header would need to be sent out every 1 second (assuming all miners participate). When new transactions are sent into the network, that some client wishes to secure against a double spend, a hash of this transaction should be spread around in the network, so that clients can confirm that their transaction is included in the block. Perhaps the system should include some way for clients to advertise which leaf hashes they need in order to confirm that their own transaction is included in the block. Ie., if I'm concerned about the two transactions "Data block 003" and "Data block 006" being double spent, I wouldn't need to be sent "0-0-0", "0-0-1", "1-0-0" and "1-0-1" as they are not needed for me to verify that my transactions fit into the hash tree.
But instead they should flag them "double-spend attempt!" and relay them. This way the network will know about the double-spend in few seconds. Then after few blocks everyone could forget them.
It is still possible that the news will not reach every node immediately, but still better than waiting for next block.
It still needs to be decided how to prevent any spamming of the network this way but this seems doable.
Not a new idea and the flooding problem has a solution too, e.g. http://sourceforge.net/mailarchive/message.php?msg_id=27901281It is still possible that the news will not reach every node immediately, but still better than waiting for next block.
It still needs to be decided how to prevent any spamming of the network this way but this seems doable.
Ideas are cheap. Got code?
Though this provides no protection against finny attacks.
Sorry if this is being slightly off-topic. If I am right here, the following approach would help greatly to reduce chances of double-spend.
The initial transactions are relayed around the network in few seconds. It is the blocks which take about 10 minutes. I understand that nodes immediately throw away any transactions which they identify as double-spend attempts. But instead they should flag them "double-spend attempt!" and relay them. This way the network will know about the double-spend in few seconds. Then after few blocks everyone could forget them.
It is still possible that the news will not reach every node immediately, but still better than waiting for next block.
It still needs to be decided how to prevent any spamming of the network this way but this seems doable.
The initial transactions are relayed around the network in few seconds. It is the blocks which take about 10 minutes. I understand that nodes immediately throw away any transactions which they identify as double-spend attempts. But instead they should flag them "double-spend attempt!" and relay them. This way the network will know about the double-spend in few seconds. Then after few blocks everyone could forget them.
It is still possible that the news will not reach every node immediately, but still better than waiting for next block.
It still needs to be decided how to prevent any spamming of the network this way but this seems doable.
Just so I understand, how does p2pool collectively commit to anything? Include the commitment in a sharechain block?
What about traditional centralized mining pools? I agree that having proof of trying is a desirable benefit.
What about traditional centralized mining pools? I agree that having proof of trying is a desirable benefit.
Imagine a mining pool. You have shares— they're really all failed blocks, they still have hashes that connect down to the transactions so you can show that the shares were an attempt to mine a particular transaction.
Now, add an extra hash to the coinbase, like merged mining, except its the hash of a prior share (of at least some difficulty). Bam. Now you have a share chain. You can use this for a byzantine consensus of who's putting how much hash power into the pool. This is what p2pool does— nodes share shares with the difficulty adjusted so that on average there is one per ten seconds. They use this to decide who gets paid and they impose some validity rules on the candidate blocks before they'll be considered valid shares, e.g. that they pay the right people relative to the share chain consensus.
There is no reason that the validity rules can't include something like "your block must include txn XXX" where XXX is some txn that previously made it into the share chain with enough fees and without yet being conflicted in the bitcoin chain. Then the sharechain itself is proof of past, current, and future effort being put into mining a transaction, as leaving out that txn would prevent you from getting paid by the pool, and you can easily extract this proof and show others. No signature validations either, just a bunch of small headers and cheap hash operations.
A centralized pool could generate such a sharechain itself internally— although if the pool was the only participant in a particular share chain there wouldn't be an incentive to not drop the txn out prematurely, so it's only evidence of past effort. To improve on that centralized pools could participate in sharechains among themselves (probably slower, e.g. 1 minute, for latency reasons), meta-pooling their payouts and providing more trustworthy evidence of future effort (and lowering their variance too, I suppose).
How are you going to p2pool mine without a blockchain? You would need supernodes or some other form of centralization.
Who knows? If I had an answer (I don't), it would probably be obsolete when the time came. There are already discussions on how to use a meta-tree to allow a node to mine without the whole block chain. A live CD (assuming CD's are not as dead as 8-tracks by then) could potentially pull all of that information off the network and into a ram drive and start mining with it. USB flash drives can already hold the block chain and would certainly be able to handle a meta-tree solution. By the time there's a possibility of 8000+ pools, a lot of evolution will have taken place and my guess is both the questions and the answers to them will probably have changed a lot.
I just thought about possibility of using Assurance contracts
Create such transaction with high miner's fee, ask specific miners to chipin one satoshi to indicate their commitment, and then broadcast the transaction to let everyone know that there is indeed the majority of the network behind that transaction.
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and web page translation. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.
Create such transaction with high miner's fee, ask specific miners to chipin one satoshi to indicate their commitment, and then broadcast the transaction to let everyone know that there is indeed the majority of the network behind that transaction.
In general, could Assurance contracts serve as a voting system?
That's arguable since p2pool mining requires a blockchain and regular pool mining can be done on a computer with just a livecd.
That's how it is today, but that is almost certainly not how it will be the day 8064 discrete mining pools ever come into existence.
How are you going to p2pool mine without a blockchain? You would need supernodes or some other form of centralization.
Also, I consider it a concern because there are no rules in the system preventing it. Sorry, but your guess as to what will happen just doesn't satisfy me.
There are no rules preventing me from repetitiously slamming my own head on the sidewalk, but it can be safely said it is unlikely to happen because there is no incentive to do such a thing. As difficulty tends to infinity, the likelihood of someone solving a block by themselves in their own lifetime approaches zero, and so it's a pretty safe bet it's not going to be very popular as time goes on.
But 4032 pools that solve one block a month each doesn't sound entirely unreasonable to me, but I'll concede it is not a pressing issue and one that could be solve fairly easily as long as transient miners don't become an issue.
1. You can ask miners not to follow certain longer block branch, but the have the opposite incentive.
Which miners would have such an incentive?
They would only follow it if the majority of miners independently asserted that they don't want to follow it if a majority of other miners say the same thing. And there is always an incentive, or at least no disincentive, in following the majority of miners.
2. You can't tell nodes or miners to invalidate blocks even if you have a proof of dishonest behavior, because that will give you a tool to invalidate blocks in the past. And that would give you a tool to revert millions of other (unrelated) transactions!
It is not a message that says "Please invalidate arbitrary block X". The only kind of block that can be invalidated is a brand new block containing a conflicting transaction never-before-heard by the majority of miners, only after the majority of miners has actively committed to some other transaction they in fact have already heard about, and only after the majority of miners have reconciled with one another to agree that that's what happened. However, my suggestion is rather off-the-cuff and could be infeasible - please provide an example of how you figure it could be used in an attack.
Sorry, I promised to comment on your proposal in my thread: Collaboration between pools could make accepting 0-confirmation transaction safe , but then Meni Rosenfeld came up with his proposal: Trustless, instant, off-the-chain Bitcoin payments, which seemed much better all around, so I stopped thinking about your post too.
When a miner commits to include a transaction into a block, essentially it means that he promises to mine on top of a shorter blockchain if necessary. The condition could be to mine on top of a blockchain that is no shorter then by one block to thwart Finney attack, two blocks to be immune to extended Finney attack with two premined blocks or even six to make the attack unrealistic. But a miner has to know that he is not alone in this, and that the shorter blockchain will eventually become the longest, otherwise he makes himself open to the attack where he would lose mining time.
In my proposal it was solved with multisig transaction, but that would bring more centralization to Bitcoin. In yours there has to be additional protocol for that.
I just thought about possibility of using Assurance contracts
Create such transaction with high miner's fee, ask specific miners to chipin one satoshi to indicate their commitment, and then broadcast the transaction to let everyone know that there is indeed the majority of the network behind that transaction.
When a miner commits to include a transaction into a block, essentially it means that he promises to mine on top of a shorter blockchain if necessary. The condition could be to mine on top of a blockchain that is no shorter then by one block to thwart Finney attack, two blocks to be immune to extended Finney attack with two premined blocks or even six to make the attack unrealistic. But a miner has to know that he is not alone in this, and that the shorter blockchain will eventually become the longest, otherwise he makes himself open to the attack where he would lose mining time.
In my proposal it was solved with multisig transaction, but that would bring more centralization to Bitcoin. In yours there has to be additional protocol for that.
As an example, upon receiving a block that invalidates a confirmation, an IPC-participating miner could broadcast a message to the other (up to) 2016 miners saying "Hey! I don't like block X because it forces me to fail on a commitment, and I propose attacking it." If the majority of miners send that message, they could follow it up with another message: "It looks to me like a majority of the mining power doesn't like block X, so I am attacking/ignoring it."
This is where you briefly touched it.I just thought about possibility of using Assurance contracts
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and web page translation. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.
Create such transaction with high miner's fee, ask specific miners to chipin one satoshi to indicate their commitment, and then broadcast the transaction to let everyone know that there is indeed the majority of the network behind that transaction.
That's arguable since p2pool mining requires a blockchain and regular pool mining can be done on a computer with just a livecd.
That's how it is today, but that is almost certainly not how it will be the day 8064 discrete mining pools ever come into existence.
Also, I consider it a concern because there are no rules in the system preventing it. Sorry, but your guess as to what will happen just doesn't satisfy me.
There are no rules preventing me from repetitiously slamming my own head on the sidewalk, but it can be safely said it is unlikely to happen because there is no incentive to do such a thing. As difficulty tends to infinity, the likelihood of someone solving a block by themselves in their own lifetime approaches zero, and so it's a pretty safe bet it's not going to be very popular as time goes on.
Unrelated, a calling card scheme might allow the miners to detect Finney attacks and coordinate the rejection of the block containing it.
As an example, upon receiving a block that invalidates a confirmation, an IPC-participating miner could broadcast a message to the other (up to) 2016 miners saying "Hey! I don't like block X because it forces me to fail on a commitment, and I propose attacking it." If the majority of miners send that message, they could follow it up with another message: "It looks to me like a majority of the mining power doesn't like block X, so I am attacking/ignoring it."
Two problems with your proposal to punish rough miners:
1. You can ask miners not to follow certain longer block branch, but the have the opposite incentive.
2. You can't tell nodes or miners to invalidate transactions even if you have a proof of dishonest behavior, because that will give you a tool to invalidate blocks in the past. And that would give you a tool to revert millions of other (unrelated) transactions!
Now you have created a new type of double-spend attack by a rough miner that includes a (previously rejected) transaction on purpose.
What if bitcoin grows to the point there are 8064 pools?
I am not considering this as a concern, because I believe the number of traditional pools will tend more to zero, not infinity, as P2Pool evolves to satisfy the needs that currently drive people to traditional pools (a lot of which I believe is just that - "tradition" - they set themselves up to use some other pool at some point in the past and it works so why mess with it. Or they consider setting up to mine on a traditional pool to be easier than setting up P2Pool - something that can change)
That's arguable since p2pool mining requires a blockchain and regular pool mining can be done on a computer with just a livecd.
Also, I consider it a concern because there are no rules in the system preventing it. Sorry, but your guess as to what will happen just doesn't satisfy me.
What if bitcoin grows to the point there are 8064 pools?
I am not considering this as a concern, because I believe the number of traditional pools will tend more to zero, not infinity, as P2Pool evolves to satisfy the needs that currently drive people to traditional pools (a lot of which I believe is just that - "tradition" - they set themselves up to use some other pool at some point in the past and it works so why mess with it. Or they consider setting up to mine on a traditional pool to be easier than setting up P2Pool - something that can change)
What happens if there are 8064 miners all with equal hashing power? Even a partial confirmation from all 2016 of the last blocks' miners would only account for 25% of the network.
This might be a concern if Bitcoin were mined chiefly by solo miners. The higher the difficulty gets, the less likely that will ever be the case. Most mining is done by pools (traditional and P2Pool).
Let's consider traditional pools for a moment. As long as they exist and have the majority of the hashing power, they will always be represented in the last 2016 blocks.
Now let's consider P2Pool. Admittedly, I did not consider much about how P2Pool would interact until gmaxwell said something. But P2Pool could collectively commit to a transaction simply by including that commitment in one of its sharechain blocks, as he seemed to suggest. All other P2Pool workers would be required to honor the commitment if they honor the sharechain block. If it worked that way, then all that needs to happen for all of P2Pool to collectively commit, would be for any P2Pool miner to solve a sharechain block after having heard about the transaction, which would result in it being shared across P2Pool's p2p entire network.
What if bitcoin grows to the point there are 8064 pools? That's only 8 million miners with 1000 miners per pool. Doesn't sound too unreasonable given that is only 0.11% of the worlds population. Also the same problem exists with 4032 since you're only representing half. In addition, many pools are smaller than 1000 users.
Sure, that's a distant possibility, but we shouldn't add scalability problems. I suppose we could bump up the number of block later (and only the pools would need to upgrade), but we may run into a problem with transient miners. It may not be possible to get confirmations from half if say mining is only done in the winter by most people due to the heat production involved.
What happens if there are 8064 miners all with equal hashing power? Even a partial confirmation from all 2016 of the last blocks' miners would only account for 25% of the network.
This might be a concern if Bitcoin were mined chiefly by solo miners. The higher the difficulty gets, the less likely that will ever be the case. Most mining is done by pools (traditional and P2Pool).
Let's consider traditional pools for a moment. As long as they exist and have the majority of the hashing power, they will always be represented in the last 2016 blocks.
Now let's consider P2Pool. Admittedly, I did not consider much about how P2Pool would interact until gmaxwell said something. But P2Pool could collectively commit to a transaction simply by including that commitment in one of its sharechain blocks, as he seemed to suggest. All other P2Pool workers would be required to honor the commitment if they honor the sharechain block. If it worked that way, then all that needs to happen for all of P2Pool to collectively commit, would be for any P2Pool miner to solve a sharechain block after having heard about the transaction, which would result in it being shared across P2Pool's p2p entire network.
What happens if there are 8064 miners all with equal hashing power? Even a partial confirmation from all 2016 of the last blocks' miners would only account for 25% of the network.
Jump to: