Mining and minting at the same time

It’s like having two people check your mailbox at the same time. It works, but you don’t get twice as many packages.[/quote]

Note that this will probably change in the future. If you mint on different computers the network will reject your blocks. So you will get 0 packages.

sigmike - Now I’m confused again, when you first mentioned the protocol change to reject any 2 or more blocks with the same stake I asked how this solution allows for normal network latency and redundancy…

To rephrase, it seems to me that any given node could routinely receive the same new block data multiple times via different routes from the source node. I thought your answer (given here: Cryptoblog - notícias sobre bitcoin e criptomoedas!) implied that new incoming blocks with exactly the same kernel/timestamp/transactions would simply be ignored rather than the original valid block being rejected.

If this is true, then why wouldn’t two computers with the same wallet and blockchain data hypothetically “check the same mailbox” and simultaneously receive the same package successfully? Are you considering additional protocol changes that would identify specific machines? If so, what is the purpose?

[quote=“learnmore, post:22, topic:2816”]I thought your answer (given here: http://www.peercointalk.org/index.php?topic=2783.msg28942#msg28942) implied that new incoming blocks with exactly the same kernel/timestamp/transactions would simply be ignored rather than the original valid block being rejected.

If this is true, then why wouldn’t two computers with the same wallet and blockchain data hypothetically “check the same mailbox” and simultaneously receive the same package successfully?[/quote]

It is true. But there is a chance that your 2 computers do not generate the exact same block because they don’t have the exact same transactions. If this happens then your 2 blocks will be rejected. The odds may be low, but there’s still a risk.

So the right answer is rather “If you mint on different computers the network may reject your blocks.”

OK, cool. Thanks for clarifying again. :slight_smile:

Ultimately, I think the main point here is that there is absolutely no advantage to minting on more than one computer and possibly a big disadvantage. So don’t do it.

We know that the Peercoin network favors PoS blocks over PoW ones. Now, let’s say that client 1 (c1) generates a PoS block (b1) and client 2 (c2) generates a PoW block (b2). Both c1 and c2 announce their respective blocks to the network simultaneously. Further, let’s say that b1 reaches the miners after b2 (because it is larger in size than b2, e.g.).
What will the nodes do in this case? Will they accept b1 because it’s a PoS block and reject b2, or will they accept b2 because they saw it first and reject b1?

They will accept b1. See this thread: http://www.peercointalk.org/index.php?topic=936.0

What if c1 has a blockchain whose combined difficulty is LESS THAN that of the blockchain that c2 has. Will the network still prefer b1 which is a PoS block over b2, a PoW block?
Or does the Peercoin network ALWAYS choose a PoS block over a PoW one?

Extending this discussion further: Is there a definite order of precedence for the various factors that concern a block – e.g. “Total Number of Transactions in block”, “Total value of transactions fees”, “Total value of transactions in block”, “Size of block”, “Time for propagation of block”, “Combined PoS difficulty of client’s blockchain”, etc. – which may be used to resolve such a conflict when two blocks are encountered simultaneously?

E.g. let b1 and b2 be two PoS blocks which are announced simultaneously to the network by c1 and c2 respectively. b1 reaches all the nodes first (i.e. it’s propagation time is low), but the combined value of all it’s transactions is less than the combined value of all of b2’s transactions. For such a scenario is there a specific order of importance attached to each of the above factors, which a node will use to decide whether to accept b1 or b2?