No matter how much we love BTC, confirmations take way too long! - page 5.

bitsmichel

sr. member

Activity: 518

Merit: 250

Quote from: Sitarow on July 29, 2014, 11:23:10 AM

Quote from: TheChosenOne on July 29, 2014, 10:29:05 AM

Payment processors are the answer my mate.
You can also work with 'approved' addresses or something like that where a merchant trusts an address that has succesfully been used before.

It has been discussed over the years. Indeed what you state is the next step service providers can monopolies on.

However as Litecoin is another network that is used for payment at merchants and with the advent of scrypt asics that network will show more promise for fast stable transactions.

Bitcoin transactions are extremely fast, if you consider the slow banking system. The litecoin network may be faster, but it doesn't have such a large user base.

ensurance982

hero member

Activity: 518

Merit: 500

Trust me!

Quote from: Kazimir on July 29, 2014, 11:13:36 AM

Quote from: ensurance982 on July 29, 2014, 10:44:27 AM

Yeah, it just doesn't make sense to scam someone for a more few dollars or euros!

You probably understand this, but just to emphasize for all those people who are still skeptical: it doesn't just not make sense, it's impossible. At least not without spending many, many thousands of dollars worth of resources, and then still only have a limited chance of success.

A merchant can accept Bitcoin zero-confirmation payments not just because his customers are such nice people that they won't scam him for a few bucks (or a few hunderd bucks). He can accept Bitcoin zero-confirmation payments because of how Bitcoin works.

Again, there's a lot of theoretical debate around this (I know Peter Todd mentioned a few tricks) but in daily practice, this is what it boils down to. Bitcoin works absolutely fine in point of sale situations.

Actually, if the merchant is running a simple BitcoinQT-like terminal you could try to connect to it with your Bitcoin node. Then you issue a transaction that pays for your coffee. But at the same time (or with a slight delay, some people wrote a paper) you issue a transaction to all other nodes (and mining pools) that spends the same Bitcoin (inputs), that paid for your coffee, to an address you control. Now the merchant thinks you paid for your coffee, but in reality it's the transaction that transferred the BTC to your own account, that gets confirmed and included in the Blockchain.
But there are ways of working around this. You have to simply look for transactions that are doing exactly this and don't accept them.

Sitarow

legendary

Activity: 1792

Merit: 1047

Quote from: TheChosenOne on July 29, 2014, 10:29:05 AM

Payment processors are the answer my mate.
You can also work with 'approved' addresses or something like that where a merchant trusts an address that has succesfully been used before.

It has been discussed over the years. Indeed what you state is the next step service providers can monopolies on.

However as Litecoin is another network that is used for payment at merchants and with the advent of scrypt asics that network will show more promise for fast stable transactions.

Kazimir

legendary

Activity: 1176

Merit: 1011

Quote from: ensurance982 on July 29, 2014, 10:44:27 AM

Yeah, it just doesn't make sense to scam someone for a more few dollars or euros!

You probably understand this, but just to emphasize for all those people who are still skeptical: it doesn't just not make sense, it's impossible. At least not without spending many, many thousands of dollars worth of resources, and then still only have a limited chance of success.

A merchant can accept Bitcoin zero-confirmation payments not just because his customers are such nice people that they won't scam him for a few bucks (or a few hunderd bucks). He can accept Bitcoin zero-confirmation payments because of how Bitcoin works.

Again, there's a lot of theoretical debate around this (I know Peter Todd mentioned a few tricks) but in daily practice, this is what it boils down to. Bitcoin works absolutely fine in point of sale situations.

ensurance982

hero member

Activity: 518

Merit: 500

Trust me!

Quote from: Jace on July 29, 2014, 07:40:25 AM

Quote from: mysidia on July 29, 2014, 07:18:21 AM

I have yet to see or hear of a merchant that doesn't require a minimum of at least 1 confirmation. In theory, it might not be needed, at least if there is a sufficient transaction fee to prioritize it.

However, I believe the merchants/processors are all practicing CYA / "better safe than sorry," and requiring a minimum of 1 confirm, for even the smallest transaction, and larger transactions/operaations generally requiring 4 or more confirms.

Are you kidding? For example here in Arnhem, there are plenty of places that accept Bitcoin, and *none* of them requires waiting for any confirmations.

Doesn't matter whether you pay for a cup of coffee, or hundreds of euros for a family dinner in a restaurant. Instant payment, NO confirmations needed whatsoever. That's the ones accepting Bitcoin directly, as well as the ones using a payment provider.

So far, thousands of euros worth of bitcoins has been spent, and exactly ZERO cents have been at risk / charged back / double spent.

Yeah, it just doesn't make sense to scam someone for a more few dollars or euros! You'd really have to control a lot of hashing power to perform such a double spend effectively. If the transaction has spread and most of the nodes accepted the 'real' transaction, you're most likely fine!

greenearplugs

newbie

Activity: 5

Merit: 0

TheChosenOne

newbie

Activity: 14

Merit: 0

Payment processors are the answer my mate.
You can also work with 'approved' addresses or something like that where a merchant trusts an address that has succesfully been used before.

V8x8d

full member

Activity: 212

Merit: 101

This point will be nonsense when bank bail-ins are triggered and people are locked out of their bank accounts for days or weeks waiting to see what remains. I purchased Bitcoin as a hedge against Fiat (Gold/Silver are the best store of wealth, however are not liquid enough). If 100% of my online purchases in the future are made via Bitcoin then I care not about how I pay for my groceries/petrol. At this point the network will be secure and Bitcoin will be a store of wealth and I no longer need to worry about counterparty risk.

fonsie

sr. member

Activity: 434

Merit: 250

Start watching at 17:50
https://www.youtube.com/watch?v=m2q9pItnO0U

They also mention that altcoins are highley insecure.

Kazimir

legendary

Activity: 1176

Merit: 1011

Quote from: giveBTCpls on July 29, 2014, 06:52:37 AM

This is a legitimate complain that my friends also make.

No it's not. Really, the complaint is simply not legitimate. Let them point out just ONE situation where paying with bitcoins requires you to wait for a confirmation. This 'problem' exists only in their imagination.

Jace

sr. member

Activity: 288

Merit: 251

Quote from: mysidia on July 29, 2014, 07:18:21 AM

I have yet to see or hear of a merchant that doesn't require a minimum of at least 1 confirmation. In theory, it might not be needed, at least if there is a sufficient transaction fee to prioritize it.

However, I believe the merchants/processors are all practicing CYA / "better safe than sorry," and requiring a minimum of 1 confirm, for even the smallest transaction, and larger transactions/operaations generally requiring 4 or more confirms.

Are you kidding? For example here in Arnhem, there are plenty of places that accept Bitcoin, and *none* of them requires waiting for any confirmations.

Doesn't matter whether you pay for a cup of coffee, or hundreds of euros for a family dinner in a restaurant. Instant payment, NO confirmations needed whatsoever. That's the ones accepting Bitcoin directly, as well as the ones using a payment provider.

So far, thousands of euros worth of bitcoins has been spent, and exactly ZERO cents have been at risk / charged back / double spent.

mysidia

member

Activity: 93

Merit: 10

Quote from: Beliathon on July 28, 2014, 03:39:49 PM

It's a scarce resource, deflationary in nature. Of course it's an intrinsic property. One could've predicted that before Bitcoin was even launched if Satoshi described the limited nature of the currency.

In fact, the earliest big investors DID correctly predict that reality. Today we call those people "smart money", and many of them are "Bitcoin millionaires".

They took a risk; it appeared most probable at that time that a BTC would eventually be worth $0. It is not a fundamental law that Bitcoin is deflationary.

In fact... right now; it is inflationary in the sense that new Bitcoins are still being added to the system.

Just because the supply is limited does not mean it will be deflationary, however.
This depends on the amount of economic activity, with regards to BTC changing hands, which affects the supply and demand of BTCs.

I would like to point out --- that not even 10 million actual BTCs necessarily have to exist to support an annual GDP of 10 billion BTC, as long as only consumers are using them and merchants are not holding the BTCs; the BTCs get sold right back to the exchanges, and effectively, the exchanges eventually start working like central banks...

mysidia

member

Activity: 93

Merit: 10

Quote from: onchain.io on July 28, 2014, 04:16:51 AM

So a merchant would generally only wait for confirmations for large transactions. For small transactions it is enough to detect the transaction is in the network, i.e. more or less instant.

I have yet to see or hear of a merchant that doesn't require a minimum of at least 1 confirmation. In theory, it might not be needed, at least if there is a sufficient transaction fee to prioritize it.

However, I believe the merchants/processors are all practicing CYA / "better safe than sorry," and requiring a minimum of 1 confirm, for even the smallest transaction, and larger transactions/operaations generally requiring 4 or more confirms.

Perhaps in the future, buyers will acquire some sort of insurance card or "performance bond" requiring a small deposit with a trusted third party reputation service to demonstrate to the merchant who will publish the buyer's "Wallet Address" in a merchant-accessible database of bonded addresses.

And the merchant will treat payments from listed addresses as immediately confirmed, based on their reputation.

However if the buyer double spends in less than 48 hours, and the merchant can later demonstrate that they were given a signed transaction which not get confirmed, by submitting a copy; the buyer will be alerted and given a short time to settle up.

E.g. 5 days to replace the double spent transaction before their reputation status is suspended, deposit is taken to pay the merchant, and they get a bill in the mail in the amount of an agreed upon "penalty".

Whitehouse

sr. member

Activity: 448

Merit: 250

Quote from: giveBTCpls on July 29, 2014, 06:52:37 AM

This is a legitimate complain that my friends also make. But what they don't get tho, is the fact credit card opperations don't get confirmed instantly per se and no one ever questions credit card operations. At least with Bitcoin you can keep track of your operations in an open source fashion (blockchain). With credit cards you are just trusting they don't fuck shit up.

Just explain to them that credit card companies are payment processors and bitcoin uses payment processors with merchants anyway, so there's not much difference here except bitcoins are both faster and cheaper.

giveBTCpls

sr. member

Activity: 322

Merit: 250

This is a legitimate complain that my friends also make. But what they don't get tho, is the fact credit card opperations don't get confirmed instantly per se and no one ever questions credit card operations. At least with Bitcoin you can keep track of your operations in an open source fashion (blockchain). With credit cards you are just trusting they don't fuck shit up.

Meuh6879

legendary

Activity: 1512

Merit: 1012

almost 6 connexions per second ... in this last debuglog.
at this time with bitcoin core ... you can't emit double-spending.

corrupted pool can ... to his clients only (reward payment for mining job).

Meuh6879

legendary

Activity: 1512

Merit: 1012

Quote from: gtraah on July 29, 2014, 04:17:25 AM

Or is this what payment processors do already and we are talking about something quicker here?

Just curious has anyone looked at the other coins, and why are some stating HIGH security even more than BTC or same + MUCH faster transaction times... I just don't get it, cant we just implement the same thing? Many test coins around.

here is a debuglog of what a bitcoin core work on "delete" transactions :

Code:

2014-07-29 09:30:12 ProcessBlock: ACCEPTED
2014-07-29 09:30:55 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:31:05 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:31:20 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:31:24 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:31:24 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:31:25 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:31:39 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:31:46 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:31:46 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:31:48 CreateNewBlock(): total size 99106
2014-07-29 09:32:02 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:32:02 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:32:02 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:33:46 CreateNewBlock(): total size 131690
2014-07-29 09:35:44 CreateNewBlock(): total size 161717
2014-07-29 09:37:43 CreateNewBlock(): total size 196154
2014-07-29 09:39:41 CreateNewBlock(): total size 211865
2014-07-29 09:41:32 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:41:40 CreateNewBlock(): total size 239880
2014-07-29 09:42:30 ERROR: CheckTransaction() : vin empty
2014-07-29 09:42:30 ERROR: AcceptToMemoryPool: : CheckTransaction failed
2014-07-29 09:42:30 Misbehaving: 71.178.202.104:8333 (80 -> 90)
2014-07-29 09:43:38 CreateNewBlock(): total size 261242
2014-07-29 09:45:36 CreateNewBlock(): total size 289249
2014-07-29 09:47:35 CreateNewBlock(): total size 338067
2014-07-29 09:49:34 CreateNewBlock(): total size 373584
2014-07-29 09:51:32 CreateNewBlock(): total size 404839
2014-07-29 09:53:31 CreateNewBlock(): total size 427018
2014-07-29 09:55:29 CreateNewBlock(): total size 453724
2014-07-29 09:56:03 UpdateTip: new best=0000000000000000379b31f0c2b745a8b3fb4d084eac96cfe02ae32e29c92f0d  height=312992  log2_work=79.944163  tx=43440030  date=2014-07-29 09:55:48 progress=0.999999
2014-07-29 09:56:03 ProcessBlock: ACCEPTED
2014-07-29 09:56:39 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:57:03 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:57:11 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:57:14 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:57:27 CreateNewBlock(): total size 61321
2014-07-29 09:57:33 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:57:50 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:58:03 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:58:04 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:58:11 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:58:35 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:58:42 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 09:58:56 UpdateTip: new best=00000000000000002c1ef9a8ef203d3a491450dd024ccb06b799faaa3d29570e  height=312993  log2_work=79.944263  tx=43440159  date=2014-07-29 10:05:10 progress=1.000014
2014-07-29 09:58:56 ProcessBlock: ACCEPTED
2014-07-29 09:59:26 CreateNewBlock(): total size 46152
2014-07-29 10:01:06 socket recv error 10054
2014-07-29 10:01:07 receive version message: /Satoshi:0.9.2.1/: version 70002, blocks=312993, us=xxx.xxx.xxx.xxx, them=xxx.xxx.xxx.xxx, peer=xxx.xxx.xxx.xxx
2014-07-29 10:01:07 Added time data, samples 149, offset -1 (+0 minutes)
2014-07-29 10:01:07 nTimeOffset = -5  (+0 minutes)
2014-07-29 10:01:16 CreateNewBlock(): total size 117645
2014-07-29 10:02:34 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 10:03:14 CreateNewBlock(): total size 145349
2014-07-29 10:05:12 CreateNewBlock(): total size 171276
2014-07-29 10:07:12 CreateNewBlock(): total size 192497
2014-07-29 10:09:11 CreateNewBlock(): total size 228770
2014-07-29 10:11:10 CreateNewBlock(): total size 257364
2014-07-29 10:13:08 CreateNewBlock(): total size 282218
2014-07-29 10:15:07 CreateNewBlock(): total size 313959
2014-07-29 10:16:32 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 10:17:05 CreateNewBlock(): total size 356696
2014-07-29 10:17:51 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-29 10:19:04 CreateNewBlock(): total size 388210
2014-07-29 10:21:02 CreateNewBlock(): total size 422098
2014-07-29 10:22:59 CreateNewBlock(): total size 441849
2014-07-29 10:24:57 CreateNewBlock(): total size 459116

Code:

2014-07-28 08:26:00 ProcessBlock: ACCEPTED
2014-07-28 08:27:50 CreateNewBlock(): total size 78518
2014-07-28 08:28:57 UpdateTip: new best=0000000000000000346b539255174aa3d853c28f754008291daa47be0ea08ffa  height=312826  log2_work=79.927496  tx=43372879  date=2014-07-28 08:28:39 progress=0.999999
2014-07-28 08:28:57 ProcessBlock: ACCEPTED
2014-07-28 08:29:09 ERROR: Non-canonical public key: compressed nor uncompressed
2014-07-28 08:29:09 ERROR: Non-canonical public key: invalid length for uncompressed key
2014-07-28 08:29:49 CreateNewBlock(): total size 59036
2014-07-28 08:30:18 ERROR: AcceptToMemoryPool : inputs already spent
2014-07-28 08:31:47 CreateNewBlock(): total size 89773
2014-07-28 08:33:16 UpdateTip: new best=00000000000000000ab5d9559ad5a3889cf90308bab9bcc34c0627209d9d05f9  height=312827  log2_work=79.927597  tx=43373140  date=2014-07-28 08:33:20 progress=1.000000
2014-07-28 08:33:16 ProcessBlock: ACCEPTED

Code:

2014-07-28 05:26:44 ProcessBlock: ACCEPTED
2014-07-28 05:27:31 ERROR: AcceptToMemoryPool : inputs already spent
2014-07-28 05:28:31 CreateNewBlock(): total size 46639
2014-07-28 05:29:32 ERROR: AcceptToMemoryPool : inputs already spent
2014-07-28 05:30:30 CreateNewBlock(): total size 152087
2014-07-28 05:32:29 CreateNewBlock(): total size 186420
2014-07-28 05:34:27 CreateNewBlock(): total size 269792
2014-07-28 05:36:26 CreateNewBlock(): total size 307482
2014-07-28 05:38:24 CreateNewBlock(): total size 332938
2014-07-28 05:40:23 CreateNewBlock(): total size 365066
2014-07-28 05:42:21 CreateNewBlock(): total size 393649
2014-07-28 05:44:13 UpdateTip: new best=00000000000000001f51a864cd4901fb2a285785019df2b78080df5595208c7d  height=312813  log2_work=79.926183  tx=43367284  date=2014-07-28 05:43:35 progress=0.999999
2014-07-28 05:44:13 ProcessBlock: ACCEPTED

.
.
.

Code:

2014-07-28 03:14:07 ProcessBlock: ACCEPTED
2014-07-28 03:14:16 CreateNewBlock(): total size 30894
2014-07-28 03:16:14 CreateNewBlock(): total size 66751
2014-07-28 03:18:13 CreateNewBlock(): total size 116504
2014-07-28 03:18:35 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:18:35 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:18:40 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:18:48 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:18:55 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:12 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:12 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:12 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:12 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:12 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:16 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:17 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:36 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:41 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:41 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:41 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:42 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:42 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:48 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:55 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:55 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:55 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:55 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:55 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:55 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:56 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:19:59 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:20:00 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:20:02 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:20:02 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:20:12 CreateNewBlock(): total size 156178
2014-07-28 03:20:17 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptsig-non-canonical-push
2014-07-28 03:20:30 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:20:44 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:06 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:06 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:06 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:06 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:07 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:07 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptsig-non-canonical-push
2014-07-28 03:21:07 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:07 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:12 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:16 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:20 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:34 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:34 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:35 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:44 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:45 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:45 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:45 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:45 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:56 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:21:56 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:22:11 CreateNewBlock(): total size 203774
2014-07-28 03:22:16 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptsig-non-canonical-push
2014-07-28 03:22:37 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:22:38 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:22:38 ERROR: AcceptToMemoryPool : nonstandard transaction: dust
2014-07-28 03:22:43 ERROR: AcceptToMemoryPool : nonstandard transaction: scriptsig-non-canonical-push
2014-07-28 03:24:11 CreateNewBlock(): total size 239852
2014-07-28 03:26:10 CreateNewBlock(): total size 287654
2014-07-28 03:28:09 CreateNewBlock(): total size 319185
2014-07-28 03:28:55 UpdateTip: new best=0000000000000000353800ec6a8598f836d27836d724c9b22355d111a316ecf5  height=312798  log2_work=79.924666  tx=43362413  date=2014-07-28 03:28:31 progress=0.999999
2014-07-28 03:28:55 ProcessBlock: ACCEPTED

BADecker

legendary

Activity: 3990

Merit: 1385

Quote from: Kazimir on July 29, 2014, 05:25:11 AM

Quote from: BADecker on July 29, 2014, 05:23:05 AM

The important thing about this is that Bitcoin confirmations will rapidly outpace the speed with which fiat confirmations are achieved.

'will' outpace? it has already done so, over 5 years ago

In some ways, yes. Yet a fiat transaction at an ATM is done in seconds, with a receipt that shows your balance. It still takes Bitcoin a few minutes, usually, for confirmation.

Kazimir

legendary

Activity: 1176

Merit: 1011

Quote from: BADecker on July 29, 2014, 05:23:05 AM

The important thing about this is that Bitcoin confirmations will rapidly outpace the speed with which fiat confirmations are achieved.

'will' outpace? it has already done so, over 5 years ago

BADecker

legendary

Activity: 3990

Merit: 1385

As technology increases, confirmations will get faster and faster. The important thing about this is that Bitcoin confirmations will rapidly outpace the speed with which fiat confirmations are achieved.

Topic: No matter how much we love BTC, confirmations take way too long! - page 5. (Read 8492 times)