I think you are a little confused about how InstantX works, InstantX just locks a transaction in place for a period of time, it is secured in the blockchain separately. The cool thing about instantX is that it is adjustable, it will take around 20 secs or less (maybe 10) to lock a transaction this is  the minimum time it takes for an InstantX lock to be set. If you want to lock a transaction really quick in a smaller interval than the block time then boom you use it like that.

 But Evan created a parameter that allows you to set the transaction lock time you prefer. If you want to lock a transaction for a month you can do that too, this can be great for contracts between people you could send coins to someone but prevent them spending them with a transaction lock that expires at a later date giving you time to check that everything is good with the terms of the deal. You can even adjust it to a 10min lock and use it for POS as you are describing.

Or so many other applications InstantX is really an adjustable time transaction locking system and you can use it any way you want. Obviously the uber fast locking time is how we are marketing it right now but it is much more than that.

Plus, the blockchain still secures every transaction just like we do now. The transaction locking system is an additional more flexible layer, transactions go to blocks normally as they do now. There is no additional risk I really dont get what some users are saying.

No information on that report.

80% of the world will be interested only in clearing times, not payment processors.  You know, that whole centralized vs. decentralized thingy.



Why would a rainy day be a better time to unleash "instant" transactions if today is not that day?

I was the wrong side of a "couple" of glasses of Saturday Riocha when I made those posts originally so I apologise if they sounded over assertive, all the same I still think there's something reassuring about having the mining network do the confirmations and for them to take a bit of time.

Look at it this way. Think of the masternode blockchain configuration as a client-server architecture. The blockchain/miners are the server and the masternode network the client.

Right now, there is an elegant delineation of responsibility where ththe "client" and "server" are reasonably independent. Also, the mining process is the aspect of the architecture that provides consensus AND buries transactions in the blockchain. I just thought that making the masternode network responsable for confirmations would create a nasty coupling between these two that may be regretted. And for what ? To save a few minutes off the confirmation time ?

If a need emerges for such urgency then it's a nice card to have up your sleeve but I can see as many problems as benefits from making it the default configuration of the Darkcoin architecture - namely it departs from the classic proof or work convention.

But as mentioned, I may not have a full enough understanding of what's proposed to properly jusge.

And to add to that, the ~7% happens annually every (576x365) 210,240 blocks.

Thanks and thanks,
Oh I guess I leave my brain in stand by mode this morning ( for the 20 and 40) both will arrive soon...

Please RT

https://twitter.com/splawik21/status/559414630528090112

Good read as it relates to BTC.

http://www.coindesk.com/anonymous-bitcoin-backgrounder-policymakers/