Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitcoin is no long the only game in crypto-currency town

economist.com

Post reply on HN
Print view View original

91–96 of 96 posts

Re: Bitcoin is no long the only game in crypto-currency town

#91

Post by prepend »

grey-area wrote: post #86
jstanley wrote: post #39

Earlier quoted context omitted.

> It's really not fine at all. 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.

Actually, it really is. I've been accepting 0-conf transactions for nearly a year and had negligible double spends. 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…

All payment systems have some system of loss. Visa/MC have fraud and error that eats away small percentages and relies largely on trusting people not to defraud you.

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.

Re: Bitcoin is no long the only game in crypto-currency town

#92

Post by prepend »

seanp2k2 wrote: post #30
grey-area wrote: post #17

Earlier quoted context omitted.

A 0-confirmation transaction normally is just fine. 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.

>seconds 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 se…

But even with BitCoin you can submit the transaction and see it unconfirmed on multiple nodes within 5-30s. It may not be confirmed for hours, but it’s certaibly actionable and trustworthy enough for merchants.

The bigger problem is having full blocks forever so it never gets processed.

Re: Bitcoin is no long the only game in crypto-currency town

#93

Post by XR0CSWV3h3kZWg »

Klathmon wrote: post #75
XR0CSWV3h3kZWg wrote: post #64

Earlier quoted context omitted.

LN's security model relies on being able to close a channel before a certain block. This means that there will be periods of time that paying the fee to close a channel in time will be cost prohibitive and the security property evaporates. 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.

There is a method (which is already in LN) to prevent this which will stop the nSequence countdown if blocks are congested. From the LN paper: >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 confi…

the main repo doesn't seem to have the string timestop in it. Nor does any of the bips. What BIP was this implemented in?

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?

Re: Bitcoin is no long the only game in crypto-currency town

#94

Post by Klathmon »

XR0CSWV3h3kZWg wrote: post #93
Klathmon wrote: post #75

Earlier quoted context omitted.

There is a method (which is already in LN) to prevent this which will stop the nSequence countdown if blocks are congested. From the LN paper: >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 confi…

the main repo doesn't seem to have the string timestop in it. Nor does any of the bips. What BIP was this implemented in? 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?

I actually don't think there is a BIP for it yet... So I guess I was mistaken saying it's already part of LN (it's part of the paper, but not of any implementations).

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.

Re: Bitcoin is no long the only game in crypto-currency town

#95

Post by ExactoKnight »

cup-of-tea wrote: post #26
ExactoKnight wrote: post #7

Bitcoin 10 minute block generation times is an inherent problem that unless changed, will doom the protocol to its eventual death. 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, t…

10 minute block generation time is not a problem at all. What's a problem is every block being full.

Can you name one good reason for having it be 10 minutes rather than 30 seconds?

If you can't then you are going to lose this argument.

Re: Bitcoin is no long the only game in crypto-currency town

#96

Post by grey-area »

prepend wrote: post #91
grey-area wrote: post #86

Earlier quoted context omitted.

Actually, it really is. I've been accepting 0-conf transactions for nearly a year and had negligible double spends. 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…

All payment systems have some system of loss. Visa/MC have fraud and error that eats away small percentages and relies largely on trusting people not to defraud you. 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.

This isn't a system of loss (systemic loss?), it's an abdication of responsibility - it's giving up on the payment system having any sort of fraud protection.
Post reply on HN