That's something to elaborate in more details, not because I didn't specify it that it means it is impossible. It is more about some consensus they could follow as an ordering rule. Rather than each miners having their own rule, if they all agreed on, it would give this benefit.
Here is a simple one I thought about, but eventually that could be improved to better account for low-fees transactions that haven't been included yet:
Transactions are ordered first by
transaction fees (satoshis/bytes) (highest to lowest)
then by
transaction size (lowest to highest)
then, as an additional filter, the destination addresses of each transaction are XORed together and the lowest (or highest).

So if you don’t like the term mempool, how about unconfirmed transaction pool, as long as you know what I’m talking about. I understand the transactions are not received at the same time by all nodes and miners, that’s why I brought up as a requirement that the content of the next block has to be agreed upon early enough. And no, the blockchain still has its value since the content is only then secured with the proof-of-work requirement.

I guess the concept is easier to visualize when we have an “unconfirmed transaction pool” that is relatively “busy”. Imagine miners are all actively mining block number 1200 and have agreed to the content of block 1201. While they are mining 1200, miners (and nodes) are ordering - according to this established and agreed protocol - the other unconfirmed transactions (those not already included for block 1201) for block 1202. Once block 1200 POW is resolved, miners starts mining block 1201 and it also means block 1202 content is fixed and the network is working on establishing block 1203’s content.

This indeed imply the content of the next 2 blocks are fixed (the one being mined, and the one following it), only their headers to be established. It also means while block 1200 is mined, any fresh new transactions can expect at best to be included in block 1202 at the earliest. This introduced delay is required as the content of the next block (1201) has to be settled and ready since POW on 1200 could be resolved at any time.

In essence, this forward planning and ordering has some elements of proof-of-stake where the incentive - as a miner - is to participate and benefit from this coordination. Other miners would be left behind catching up at assembling the set of transactions when it comes time to start mining the next block. Consequently participating provides miners the ability to save precious time in the race for the next block.

And as stated before, users would also benefit since nodes would display the expected content of block 1200 (currently being mined) and 1201 (immediate block afterwards), and the work in progress for block 1202.

PS: I have unscrambled eggs regularly for breakfast

Hi Folks
While watching a video criticizing Bitcoin's confirmation time of 6 blocks was actually not even full certain  (although high probability), I thought about an improvement. I wrote this article on medium and sharing it here. I'm not sure how feasible it would be to add this extra communication between miners and nodes and the impact it would have.

https://medium.com/cotinetwork/about-bitcoin-confirmation-times-f91d2aaa1a1b


You know how it is, you send a bitcoin transaction, it gets accepted into a block, but you have to wait for at least 5 or more blocks to be added to the blockchain to have a high level of certainty your transaction is included. The reason being that it is sometime possible for 2 miners to find the next block nearly at the same time, in which case we have a temporary fork as these 2 blocks are different. Since it is possible that one of the block might include your transaction while the other did not, you would have to wait long enough until one of the chain forks wins by adding an additional blocks before the other.
https://cdn-images-1.medium.com/max/2000/1*NJJbzjHRzuOWxO1IPU2CAA.png

Figure 1 — forks
The problem is that although waiting for 6 blocks gives a high probability, it is not a complete certainty. This whole issue has been raised against Litecoin’s 2.5 minutes block time, saying it doesn’t really make confirmations faster since forks happens more often, and require even more blocks (more than 6) to get the same confirmation probability.

Obviously, this is not much of an issue when there are very few transactions happening and hence no competition for your transactions to be picked by miners. Something that is not the case today though. But what if we could improve this with a slight change that could possibly be done without requiring a hard fork? What if miners were to agree on the same set of transactions to be included in the next block? While they are currently mining the existing block, if they were to coordinate among themselves via a defined algorithm and protocol on which transactions they would include in the next block, or perhaps the next 2 blocks. Instead of having a hodge podge of transactions piled up in their respective mempool, they would be ordered and identified in which following blocks they are scheduled.

https://cdn-images-1.medium.com/max/2000/1*yws2dv1BPa6OGmf7TJ2OIw.png
Figure 2 — Coordinated ordered transaction mempool
This actually would solve more than one problem. As described, it will diminish or annihilate the uncertainty about whether or not your transactions would be included in the next block since now, all nodes and miners would know about this coordinated ordering. But in addition, it will also help miners themselves. One of the issues that miners face is to quickly assemble new transactions to create the next block to be mine. The winning miner of the last block had a head start in creating this next block while the losers have to catch up, assemble a new block based on the transactions this winning miner had picked and then start mining. Because of that, some miners decide to mine a near empty block to save time by skipping assembling transactions, making the situation worse when it comes to transaction throughput. But now, if they all coordinate in advance which transactions will be taken, all they have to do is to adapt this next block’s header to reference the winning block. Miners who do not participate in this would be at a disadvantage.

Looking at figure 1 above, block #2704 had already been loaded with transactions while miners were busy mining block #2703. Once they learn the exact details of block #2703 (the miner who won will have its bitcoin address collecting the block reward, along with other details) they create the corresponding block header for block #2704 without having to remove or replace any existing transactions they had loaded in it, hence they can start mining it right away.

In addition to such new coordinated ordering between miners, nodes will also be aware of them and as such, any users will know ahead of time when their transactions are part of a block actively being mined or just the next one after. If this coordinated and ordered transaction was made a mandatory agreement, the probability of confirmation would jump to 100% right after the first block (more on that later below).

Okay, so that’s sound very great, but how difficult or feasible would that be and how exactly could that be achieved? I believe this can be achieved with the addition of certain procedure in the selection and ordering of transactions. Here are the set of rules I can imagine that would satisfy this requirement. This will be defined as a protocol selection that all miners agree to follow.

The set of transactions in the next block to be mine (after the one currently being mined) should be fixed and already agreed. In other words, by the time mining has started on block #2704, the selection of transactions to be included in block #2705 is declared complete. At the moment mining as started on block #2704, a SHA256 of the “draft” block #2705 is shared by all miners to confirm they are in agreement. If not, they broadcast their respective draft block. The draft block chosen by all miners is the one containing the highest number of transactions, and if there is a tie, the block with the lowest SHA256.
For the following blocks after that (2706 and beyond), transactions are ordered by the transaction fees amount (perhaps a few other transactions with low fees that have been waiting long enough). Introducing some kind of transaction weight (my son’s input) that combine time in the mempool and fees could be considered. Such algorithm’s detail would have to be established.
If two transactions have been received coming from same source bitcoin address, the one with the highest transaction fee is accepted, the other one discarded. If they have the same transaction fee, the transaction containing lowest destination bitcoin address (numerical order) is selected. In other words, if a double spent is detected, the selection of which one to choose is done on the destination address.
Miners will have a very high incentives to participate in this selection protocol for the benefit it will bring them in limiting their preparation time. And as for users, the probability their transaction is confirmed goes up. But whether or not this is done, if miners were to broadcast all blocks received (like both block #2702 in figure 1) and indicate which of the 2 they have received first and are working on, and nodes did the same (showing the 2 blocks), users could know whenever there is a soft fork on the network and if their transactions is included in both branches, they have a certainty of confirmation no matter which branch wins.

As mentioned earlier, if this was made mandatory — which I think in this case might require a hard fork actually— then miners and nodes would rejects any blocks mined that do not have the established set of transactions that was agreed upon earlier. For example, a miner publishes block #2705 that has a completely different set of transactions, hence it is rejected and all miners keep mining the established #2705 until one of them wins. Doing so would bring 100% probability of your transactions to be confirmed once included in the next draft. No need to wait for 6 blocks to have a 90%+ probability, you enjoy a 100% immediately when the block with your transaction is published, or even secured when in the established draft block.

Additional note: this might help figure out the transaction fees.

Interesting thread with Vitalik involved

https://twitter.com/AnonOnAMoose/status/873226461989277696

Perhaps a miner will send you one for free, but otherwise, check this out
http://getpasa.com/

Yes, I agree about this, and I'd like to help in fixing this. I don't want to have any credits for this, I just want the documentation to be more in depth. The V2 is lacking details, it does not explain enough, particularly about the checkpointing, and how secure it can stay.
My understanding before reading V2 was according to this image I created:
http://i.imgur.com/MpDIpKj.png
Basically, on regular interval, you record the hash of the safebox and the safebox number and you can discard all prior blocks. From there, the blockchain dating from this pruning can validate any new account balance in later safebox created after this safebox you recorded.
The V2 WH says the safebox has block header information in every account block sub-structure. This does not tell me what it looks like and how it can prevent an attacker to present you with a fake Safebox that contains an inflated balance for his account. I'm looking forward to see it though.
Regardless whether there is a flaw in their concept or if it is solid, PascalCoin as it is presented in the first white paper - with the safebox - allows pruning of the blockchain on periodic interval. You just need to have the rest of the blockchain past that pruning point, either you hold these blocks yourself (as a miner or a node) or you can get it from somewhere else. From that safebox you secured the hash, you can validate all new transactions leading to new safebox post pruning, hence you can confirm an account really has the Pascal stated in the latest safebox.
BTW, the pruning would be done at least 10 blocks prior to the current block being mine so to allow everyone the time to get all the blocks propagated.

Well, that is funny, I am currently working on a re-write up in English as well.
But your doc needs graph, in particular about the pruning
This is what I've created for it in my doc
http://imgur.com/a/KGEWo

I'll be reviewing your doc,

Can someone explains or point to a blog/paper that explains why the public key is encrypted ? The blockchain/Safebox holds the encrypted public key? Encrypted with what?

http://explorer.pascalcoin.org/account.php?account=290815-10


Thanks

By the way, here is a nice feature I'd like to propose to the explorer.  The enc_pubkey is encoded differently than what is spit out by the Pascal Client. It should match or at least, both form of encoding should be listed in the explorer

http://explorer.pascalcoin.org/account.php?account=290815-10

Agree very much

I've sent you the 25 Pasc via my poloniex account 3 days ago. What's going on?

And in case a miner is in a good mood, since there are no exchange working right now to get a freaking account, I was wondering if one could add my public key below to an account?

3GhhbourowxLoA3wHBnUsSQ3zA3MaGjBpg4Ne9zj1arLC62VqMeEAn4Z2GrN3M9YMRMw8fAgUVks7kt 6KVnmwmszEiy2RrKqzWtLHv

Just let me know by replying here.

It's also an excellent way for investors to evaluate the currency - how easy to setup an account, how stable is this new type of deletable blockchain, ...
But not being able to get an account is a big thumb down right off the gate in this evaluation process.

Very much in agreement. I'm part of those investors. And not being able to easily get an account - like I could with any other coins - made me sell my Pascal Coins.

It will if it continues to be difficult for newcomers to get just a plain account.
As long as the pascwallet or any other means of getting an account is not available, expect a downtrend on the price.

Clearly, this is not ready for prime time
I just sold by Pascalcoins simply because as a new user, I wanted to use it and the wallet, only to realize the only way for me right now to get a silly account is to mine.
I may comeback to it if I see this more stable and these issues resolved.


The big drawback for this coin is the fact you can't create account just like you can with Bitcoin. Hence, it was critical that the overall system was designed to facilitate this.
I would have look at designing the coin in such a way that users can select or create their own account number rather than relaying on an exchange.
Overall, the deletable blockchain was the aspect of it that really interested me, but I didn't care much about the account-number thing and so far, that's is the achilles heel of this coin. I understand it might make life easier for grandmas to have simple account...  but I don't see how with this complicated account assignment

Would that be
https://www.pascwallet.com

Seems down.

Hi  guys
I found Pascal Coin deletable blockchain feature quite interesting.
However, there is a drastic need to make it easier to get accounts.
I downloaded the wallet and created a private key, but I need an account

There should be a website that allows for people to get access to that

Can anyone point me to this?
Otherwise, here is my public key that I'd like to have assigned to an account if one has an extra one.

3GhhbourowxLoA3wHBnUsSQ3zA3MaGjBpg4Ne9zj1arLC62VqMeEAn4Z2GrN3M9YMRMw8fAgUVks7kt 6KVnmwmszEiy2RrKqzWtLHv


Thanks

More readable format with pictures
http://philchampagne.github.io/xsidechain/Side_Chain_without_Bitcoin_modification.pdf

Indeed, the devil is in the detail. Good point! Thanks for bringing that up
The easy solution is, as a requirement, the side chain block must be signed with the private key corresponding to the bitcoin address of the winning miner (or runner up). In the case of runner up, it's not really required since it will not be published as opposed to the winning block as you stated.