For me the issue of security with coins is not necessarily mostly about technical issues first.

It's what make bitcoin very successful is because it make in sort everyone participate get some reward somewhere. It's secure because 51% of users keep it so because they have an interest to do it.

With pos ok some people could buy all the coins and screw the chain, but what does he win ? nothing, he just lose all his money dry. No point in doing this.

And i think for small chain, pos can be more secure because with pow there can always be the risk someone outside the network come with some asics and over power it, with pos it need someone who has coin and is on the network. For small chain i tend to think the risk is still smaller with pos than pow.

And there is something i find really nice with pos, is the authority on the chain can be distributed very easily, maybe it's not very useful in the perspective of coins, but if something like a "proof of authority" could be useful in some scenario, with pow it would need the node to compute a big thing to prove it has the pow, and it would need to do this each time it need to give a "proof of authority", and it would be a big waste, and harder to be sure it's distributed evenly between a certain number of entities, with staking just need to check the network weight. And it make it much easier to distribute the authority on the chain, in certain case it can be interesting.

Maybe some small proof of work should be added to the stake modifier computation to incite people keeping on a single chain to make it a bit more secure.

What i would try to solve this problem is :

Associate a number to each op code in the script to represent the computing time it take, all node need to have this same values.
Each time the vm execute an op code, it increase a counter with this value.
When the block is being mined , a counter is kept by mining node for this block.
When the block is emitted this value is put either in the block header, or in the coinbase input script.
On the "client" side, the consensus decide what is the maximum value for this number for valid blocks.
On the "client" side, a limit is on put on the vm and the execution is stopped when the counter reach this limit.

Normally it shouldn't be to hard to do in itself. And should be effective to keep the execution time in certain boundaries.

Not saying i will do this in the afternoon, for the moment i have plenty of things to do lol But the problem is to be able to reach the consensus on the update, good moves need to be planed before to see how it's supposed to evolve.

If you want to go with an unlimited dragster, at least make in sort it has some kind of brakes, otherwise there can be some accidents :p

Common sense is 20% of bitcoin users :p it's always like this, 20% is still good

It's why good dev must be like dark vador, pushing what is good for their user on them with an iron hand, otherwise they never understand anything. . It's end less debate, lack of consensus, and it never go anywhere  

Maybe an indicator of the total estimated processing time for a block could be added in the block headers, and limiting the efffective processing time to this. If it's not processed before the indicator,  bye.


or advertising the number of sig op in the block more explicitly from start, and limiting the number of sigop processed to this, if there is more sig op than advertized, bye, as mining nodes are already supposed to know this, if a way can be found not using too much extra bandwidth.

Optimisation can be seen in differents ways.

Here the concern is resources availabilty. The goal is too keep resources available a maximum, to keep the processing capacity at maximum possible, which include not wasting it on useless computation.

If the solution to maximise capacity in case of useless long block is to monopolize the ressource to check them, it's not really a big win. Ok that remove some of the processing from the main thread, it doesn't mean it's free either, or that those resources could not be used for something more useful.

With the nature of blockchain there will always be some time wasted to invalidate some long stuff, but if the goal is to optimize this, need to find a way to avoid this processing in a way that is shorter than actually validating it. Otherwise it's just pushing the problem away. If there was always some idle core who has nothing better to do than checking useless block, I say ok it's a win, otherwise it's not solving the pb.

With the thread thing it can ceil the waste to the time of longest block, which can maybe be a win in some cases.

The thing is i'm also thinking on general blockchain problem, because i'm trying to generalize blockchain stuff with a generic engine, and trying to generalize issue not depending on a particular blockchain topography or other blockchain / network specific thing.

Maybe for the current bitcoin configuration that can work, but if you take POS coins for example, where blocks can be sent more easily, or other configuration, it can be more of a problem.

Even if there are multiple core, there is still not an infinity of cores. If there is a finite amount of such block who has to be processed, a finite amount below the number of core, that can be ok.

Otherwise it's just pushing the problem away using more of finite resources.

If there is only a couple of them possibly being processed at the same time, that can help.

But still the goal is to avoid wasting processing time on them, not wasting more of it on multiple thread.

And there can still be this issue on single tx no ? It's not necessarily coming up only with solved blocks ?

And in that case there can still be many degenerate tx with sigops not coming only from the pools.

That could improve a bit if there few blocks like this. But even if you can work the issue of shared access & deps, then what if there 100 such blocks ? Or 1000 ?

It can maybe just improve the resilience if there is few of them, but it's  just pushing the pb one thread away, and there isnt an infinity of processing power on a computer, even with threads.

Hence the real solution is more on how to avoid wasting processing on those blocks, rather attempting at processing them as long as no better block is validated. Instead of increasing this wasted time on several thread to buffer a bit the excessive processing time.

Yes I didn't look in depth yet into it, so I might have a wrong idea I know im missing many things about it

I can understand the part with merging transactions to spare some from being mined, the case you present is case where its useful,but as the tps ratio of LN is still much higher, do you have a rough idea of how many tx can really be saved this way, and it can garantee the tx from a locked tx will be updated to the blockchain before the lock expire ? Like there will never be a flow of merged tx who would take more time than the lock to expire ?


Cause LN as no way to notify the other node or force them to extend the lock if that happen right ?

For me it's still the pb that the volume of merged tx to be synchronized back on the chain must be kept under control, otherwise it's bit like fractional reserve on the tx processing power. With the same potential issue if everyone want to get their tx back on the main chain all at once.


It's why to me it would be somehow cleaner to mark those tx with a special marker to say they are indefinitely locked  on LN, until another tx from LN make them available again.

That would mean probably slight upgrade  of the protocol because such tx would have no point in an "intra chain" view, as it would make the bitcoin just virtually disapear entierely from the chain, but that would be somehow more clear, and would solve the expire issue.

Because the only thing that I see a bit weird is that it still make the btc state in a sort of Split, they are marked as locked on the chain, meaning there is no way anyone on the network can move those coins before the lock expire, whereas they are effectively moved on the LN, without there is anyway to know it can even possibly happen from the chain.

And it seem dangerous to put a non reiterable timeout on the lock when you cant have a very good predictibility of if the state can be fully synchronized back with the blockchain in this time.


But that's mostly the concern id have with it, otherwise it seem a good idea in the principle, clearly something to be tried.

 

Everyone wants more tps, but doesn't look like segwit/ln is going to become the solution in near future :p

I know 

Promise the new website is online tomorow, in first version

After I will update some number of js widgets to many different things like block explorer and the 3d, and bounties to have number of easy to integrate js components for boostrap

 Sorry for lack of news !

It's a bit the idea with how im doing purenode

https://github.com/iadix/purenode

And there is already a multi thread sse raytracer that works with it

With the code im doing with purenode, I have good hope it will bring great simplification to the code base and allow for experiment to be kick started more easily and normally it's already thought from the first asm instruction to be thread smart, with object references, atomic instructions & all. And it should adapt to most chains, including btc.

For me it's more a question of macro organisation than power grabbing.

If you take for example how a good caching proxy or intranet solution would work to optimize the traffic and caching, because they have access to all the traffic from the subnetwork,  and can optimize and cache a certain number of things more efficiently because they have a "meta node" view of the whole traffic, it can know what other node of the subnet are requesting or sending to who, and that can allow for some macro management which is impossible to do on a single node level.

Even if it allow some optimization on the local subnetwork due to macro management, you wouldnt say it's "power grabbing" or even hierarchic, even if it see the traffic on a level above the individual nodes. The role is still mostly passive, just macro management, and already I believe this could open way to optimize bitcoin traffic inside of subnetwork.

And only what really need to be read or sent outside of the local network will really be sent. Aka mined.

It's more this kind of idea than introduction of true layer or hierarchy


I can say I have been doing my lot of pretty hard-core stuff with cores and interrupt & stuff, if there is a constant I can say in thus thing is :

 you want something to scale ? You have to divide it into independent subset who can be processed separately.

That's the only golden rule for good scaling.

Can call this fragmenting or hierachizing, but it's just about organising data in sub group when it make more sense to process them by group because they are highly related with each others.

Kinda like octree are used in video game to limit the amount of computation a client has to do on what he can see or interact with.

Not that those subnetwork have to be static or follow 100% deterministic pattern, and can be adapted when it make sense if certain nodes interact more with certain addresses than others.

It's why if anyway the alternative are being stuck with a slow inefficient consensus, or going a full private network where all the transaction will be shadowed, why not bastardizing a bit the way node works to deal with private processing of certain intermediate result.

Because anyway, as far as i know, LN is not going to solve much more than this, even if it's still better because it has true mechanism of confirmation, but as this mechanism of confirmation is still not completely as safe as pow, it still imply weakened security.

And if it's to be used as a private network of trusted node anyway, with no way to make sure it's completely in synch with the rest of the network, maybe it's not worst to make it more explicit and make mechanism to allow faster/cheaper transaction between trusted party outside of the memory pool, and only pushing the transactions to the memory pool when it's more optimal, and eventually reworking the whole transaction flow to make it more optimal at the moment it has to be mined. And keeping the intermediate operation only privately in the network.

It's more about having private agreement between nodes that is not necessarily based on the blockchain

Not saying this should be assumed as the norm, but when several node could reach off chain agreement on how the transaction flow is supposed to be timed on their side, it can still allow for optimization, if the intermediate results doesn't need to be seen on the whole network.

Or otherwise need  a better definition of transaction flow to allow decentralized optimization in the case it can make a difference, but it's also bloating the whole network for things that  can be kept private without making big security problem for the party involved.


I guess i'm more like anakin skywalker   I care about objective, result and timing. Consensus is too slow. You need to understand the real nature of the force  

The consensus have to agree on the end result but they dont always need to know all the details :p

It's why another tx pool could be made that is only shared between trusting nodes, with it's own pre processing, like this useless or bad transaction are never even relayed to the mining nodes at all through the memory pool. But intermediate/temporary result can still be seen in those node. Even if they don't necessarily need to be confirmed or mined before a certain time.

I was thinking about something in this same line, having the memory pool used as some kind of optimization layer above the block chain, to pre process certain transaction and spare them from the mining pool.

But in the same time, i'm thinking memory pool already have their specific purpose for the miners, and i'm not sure it's that easy to introduce more complex logic in the mem pool algorithm directly, and it could make its real purpose and functioning more complex.

But maybe something like a completely different transaction pool could be thought before the memory pool, where eventually all the data temporality is taken in account, and how often the input/output will change, it can do the operations in the cache in non confirmed manner, to save up mining fee and confirmation time on intermediate result, in case it's explicitly clear that the intermediate result are non confirmed and the party used this memory pool can accomodate with temporarily non confirmed tx ,and only push the tx in the actual mem pool when they are not going to be used in the cache for a little bit, or a new input from those tx enter the memory pool.

It could make sense if several node in a related commercial network would share such an alternative tx pool when there is high number of tx chain that can be easily verified because they all originate from the same trusted network. And it could probably save up a number of intermediate operation on the blockchain, without giving too much security problems. With the drawback that those transaction could only be visible in this network the time they are finally push to the main memory pool for mining. And they would still be 'temporary' transaction as long as they are not push to the main memory pool and mined.

That would not replace true blockchain confirmation when it's needed, but in certain case it could probably make some sense when data temporality can be predicted because lot of operations on this data happen in a trusted network subset.

Like taking a e-shop and a supplier, who would have enough mutual trust with each other, the customer would put orders on the transaction cache, but maybe the shop will only collect them at the end of the day, and they don't have to be mined instantly, but to be still on the network. And then maybe the supplier also will not collect the shop orders before a certain time too, and the tx from shop to the supplier don't need to be fully confirmed before a certain time. Or certain intermediate result can be totally skipped from the memory pool.

Or making a memory pool who can fully take in account data temporality with more marking to have better optimization on when the transaction really need to be mined. Or when some operation can be done and intermediate result skipped from the memory pool.

 But i'm not sure it's a good thing to do this directly in the main memory pool because not every body will necessarily agree, or this behavior should be completely optional and explicitly requested for certain transactions when it can make sense to optimize data temporality before the mining.

https://youtu.be/4xVSYrZsnsQ :p