That being said we really should see exchange -> exchange txs be conducted over large LN channels, it could off load a lot of pressure off the chain.
>For example, if a parent transaction output is spent by a child with a nSequence value of 10, one must wait 10 confirmations before the transaction becomes valid. However, if the timestop flag has been set, the counting of confirmations stops, even with new blocks. If 6 confirmations have elapsed (4 more are necessary for the transaction to be valid), and the timestop block has been set on the 7th block, that block does not count towards the nSequence requirement of 10 confirmations; the child is still at 6 blocks for the relative confirmation value.
>This gives sufficient time and block-space for transactions at the current auxiliary timestop block height to enter into the blockchain, which can prevent systemic attackers from successfully attacking the system.
It's not perfect by any means (a malicious miner with a significant portion of the hashpower could never set the timestop bit and spam the mempool at the same time), but it mostly removes this worry in a "normal congestion" scenario, and makes it require a pretty large portion of global hashpower as well as very VERY deep pockets to pull it off in a "malicious" scenario.
Seems like a decent idea, although I don't see why miners would be incentivized to set timestop and the paper suggests that timestop is set to 1 whenever the block is full. The blocks are almost always full, so is it just up to the miner to choose if time is stopped or not?
But the idea relies on miners "doing the right thing", and in this case since there isn't any downside for following this rule, the assumption is that miners will act in good faith.
>The blocks are almost always full, so is it just up to the miner to choose if time is stopped or not?
It's not necessarily if the block is full that the bit is set, but rather if there is "network congestion". This can mean many things to many people, but the assumption is that if fees go up significantly over a short period of time, that could indicate congestion which miners would set the bit on, or perhaps if the mempool of pending transactions gets over a certain BTC amount, it could be set.
Also, I completely forgot to mention the other piece that makes all of this much less worrisome. If you need to broadcast any transactions to prevent "theft" of your BTC, you will receive all of the BTC in the channel by doing so. This gives you the ability to make a child-pays-for-parent transaction with the UXTOs from the channel closure (in a contract revocation scenario) with an absurdly high transaction fee to guarantee inclusion in the next block (basically using ALL of the other party's money as the transaction fee).
Technically, the other party in the channel could also do a CPFP to try to get their transaction included before yours, but as long your side of the channel never went to 0 at any point, you will always be able to "outspend" the other party for transaction fees.
If you can't then you are going to lose this argument.
It's really not fine at all.
The competition is full confirmation transactions on a debit card or bank account in seconds with much lower or zero fees.
Actually, it really is. I've been accepting 0-conf transactions for nearly a year and had negligible double spends. https://incoherency.co.uk/blog/stories/zeroconf-payments.htm...
The small number of double-spends that did occur since I wrote that blog post I think are mostly due to bad luck (and opportunism) rather than malicious intent upfront, and represent only ~0.1% of payments.
So your approach to preventing fraud is... to trust people not to defraud you?
Glad it worked for you with bitcoin and the particular people using your service, but that's not really a good basis for a payment network. There are multiple other problems with bitcoin as a payment network and currency, the delay in transactions (which prompted your experiment in ignoring a key part of the currency) is only one of them.
If you run Starbucks and serve 1000 transactions per day, you’ll have some fraud. If 0.1% are fraud, that’s not too bad.
1-The current solution is worse on this dimension.
2-Since Bitcoin Cash doesn't have replace-by-fee this is impractical for any small transaction.
3-Most of the situations that need to be immediate are small--with the large ones it makes sense to wait.
I have no idea why you think that's related to time to confirm that a customer has money to pay for goods, which is an entirely unrelated problem which bitcoin solves badly in comparison to current payment networks, and due to its distributed nature is unlikely ever to solve well.
At PoS systems in the US, it's typical to have to wait 30+ seconds for chip cards to go through. I'm guessing that this has more to do with the PoS system / slow internet connection for the store / slow network on the back-end card network, but cryptocurrencies would need to be sub-minute to be ~acceptable for in-person retail transactions.
Until that is solved, until cryptocoins are more than speculative securities where the value is only the current market price on a handful of exchanges, and until you can use them to realistically buy and sell things instead of using cash or a credit card, I don't consider them a "real" currency (by my own definition). I DO hope that it gets there some day, but I don't see that happening for at least another 5 years, likely with quite a few people who put a significant amount of money into it getting burned quite badly.
[1] https://squareup.com/townsquare/weve-chipped-away-at-emv-tra...
The fundamental problem with bitcoin is that it is decentralised and trustless, and those two properties preclude fast transactions at a global scale - for that you need a federated system with trust between nodes. If you remove those properties, you're no longer using anything resembling bitcoin, and why not use a system with proper validated parties in the first place?
The bigger problem is having full blocks forever so it never gets processed.
Seen it couple times.
No. Those do not compete with trustless digital money. If you think that then you don't understand the point of Bitcoin. It's like saying landlines are better than mobiles because you can never misplace them.
For larger amounts, you want confirmations, but then it's generally alright to wait a little while for confirmation, too.
Note that replace-by-fee means this only works with Bitcoin Cash.
It's like trying to make a 56k modem work, when broadband is available.
When litecoin came around a few years ago these were abstract problems, but now that transactions with $10 fees take 36 hours to confirm... the issues are real and a switch needs to happen. Lightning network or not, these hacks to speed up the network unequivocally make more sense to do on a network with faster block generation times. Necessity will force this outcome.