Topic: The Slow transaction speed [confirms], solutions, discussion. Wide adoption - page 3. (Read 4099 times)

Whatever happened to the green address idea?

but this is more like real world larger adoption....so good demonstration

This is also one of my views

I don't frequently send amounts less than ฿1 around, but, I've never had to pay a transaction fee. I mean, it would be awesome if sending 10¢ could be free (computationally and fee wise), but, the technology simply isn't there yet for that. Thus, the fee.

The miners set the fee that they are willing to accept. The nodes bear the storage costs, but they have no say on the fee process. The default relay settings for dust is the only defense of storage costs and we have been trying to make fees so this job. Hopefully dust reduction (combined with fee reduction) will help push the lower limit on ฿ transaction value down a bit and speed up confirms. 

Yes, the way to make Bitcoin successful is to block sites that use it in ways you dislike.

Most often, slow confirms are caused by the sender not attaching a mining fee. Pay the tiny fee, and the transactions is very likely to be confirmed in the next block.

Ripple, right now

accepting checks (cheques) is not the same risk as an unconfirmed bitcoin, the closest comparison would be a fake bank note and not having a UV lamp handy to verify its legitimacy for atleast 10 minutes.

this is why vending machines have coin/note checkers built into them, even for small priced items. as fraud is a big thing

I don't see this being a big deal. Merchants take checks which suffer from the confirmation problem, right? The difference with a check is that you know who wrote it. If someone wants to pay with Bitcoins and skip confirmation, then perhaps knowing who they are and where they live would solve the problem?

the slow confirms is caused by spam transactions which clog up the unconfirmed list. block satoshidice and other "on the chain" gambling sites and the problem is solved.

Have you looked at Bridgewalker?

https://www.bridgewalkerapp.com/

It deals with accepting the risk, and minute-by-minute pricing anomalies as well.  For a merchant dealing with sub-$100 transactions - down to pennies - it's something to look at if you want instant settlement.

shortening the blocktime is not just a tweak. it also involves OBVIOUSLY messing with the reward pay out. because if there are only going to be 5.25million coins produced in the next 4 years. at a rate of 3600 a day. then shortening the blocktime will mess with the maths of rewards and difficulty, etc etc.

so a 10 minute estimate for 25 coins would need to become 12.5 coins for 5 minute estimate. just to stay on track for the 5.25mill coins by 2017. which makes it less profitable for NON-asic miners as they have to push even harder to solve the block in half the time for half the reward. the ripple effect of messing with the block timings is a silly fools errand that will cause more issues then solve

+1

There's also the option of shortening the block time in bitcoin in the next hard fork. It would just be a parameter tweak so possibly acceptable to the majority.

as some people are now realising sending out 2 transactions is easy, but getting them confirmed 10 minutes+ later is the 'near' impossible part. so accepting 0 confirms is definitely a risk as you never fully know until the 10th minute (first confirm) if its a double spend or not.

even if they get rejected at the 10th minute, because double spends are theoretically hard to achieve. that's still only provable at the 10th minute.

however the option of a payment service which accepts coin to get pre-confirmed, to then use later throughout the day. such as a loyalty/value card system for small daily lifestyle amounts of value would totally eradicate this risk.

much like how MTGOX use to pre-confirm funds to then allow MTGox codes to transfer bitcoin balances between members instantly/risk free.

i would happily put 0.1BTC into a service while i take a shower in the morning, knowing by the time i get to starbucks or want a morning breakfast in a cafe i can spend it instantly without question.

MTGOX missed out on a key feature for their merchant gateway by removing the gox codes. but then again i would not suggest MTGOX for merchant services due to the lack of support/current issues.

Far from perfect, but works:

You deposit bitcoins into your online wallet hosted on a reputable site, you only keep small amounts here for quick transactions like buying gas.
When you buy your stuff, the intermediary site issues an IOU to the merchant, which will be settled on the same day or something.

You risk only small amounts, merchant risks the last few transactions  if the intermediary goes down, not a big deal. It's similar to how
things are today with credit cards, but still faster (for the merchant) and cheaper.

At some point BTC will only be suitable for very large transactions, which is where Litecoin (or one of the 10 or so derivitive coins) would step in to fill the need for micro-transactions.

This won't help against a Finney attack.

There is no a solution based on blockchain+PoW combo. Other currencies use smaller gap between confirmations but they r less secure. The risk of double-spending is in inverse proportion to time of waiting, no matter how many confirmations u get.

U could pay attention to cryptocoins based on other approaches:
1. Ripple (in beta stage)
2. Qubic (in alpha stage)
3. Decrits (in concept stage)

Consider that there are two types of transactions:

a) Wait for confirm. Where the merchant can wait for n confirms, based upon their appetite for risk, and size of transaction, before delivering goods. This works for most on-line purchases.

b) Can't wait for confirm. Where the wait time can't be any longer than existing fiat systems, say 10 seconds, such as when buying petrol or paying a restaurant. These are usually face-to-face. Zero confirms seems acceptable for small value transactions, less than $20 perhaps, but might be unacceptable for anything larger.

So your problem comes down to face-to-face transaction confirmation where product delivery needs to be immediate.

The best solution I see is improved merchant-version Bitcoin client software which connects to a lot of nodes in order to detect a double-spend attempt as fast as possible. At the moment nodes silently ignore double-spends so that they don't go into blocks, but perhaps this could be changed so that they are propagated for a short time, but flagged as double-spends. Merchant nodes will detect these more reliably.

The other solution is a personal bitcoin guarantee card up to a limit. Might be a continued role for banks in a Bitcoin economy. Banks would need a fee for insuring against fraud when these cards are used.

The confirmation process does take time, but the acknowledgement of an issued transaction by the miner network takes only seconds. Given the practical impossibility of double-spending, the presentation of the transaction to the network is a pretty good indication that it will be confirmed. What the confirmation really does is enable the recipient to "spend" the btc received.

This assumes that most transactions are not attempts to double-spend. Does anyone have stats on how many transactions are rejected as double-spend attempts?

Consider that a credit-card approval is also only provisional. It can be reversed for many days after being received. Once a btc transaction is confirmed, it cannot be reversed.

My thought is the merchants should just warn the customers that they will not deliver for bitcoins coming from addresses with unconfirmed transactions, this should be enough to prevent race attacks, for anything worth enough for a Finney attack, it's recommended to just wait for several confirmations.