Bitcoin Forum
December 10, 2016, 01:20:06 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 [1397] 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1807376 times)
Erdogan
Hero Member
*****
Offline Offline

Activity: 714



View Profile
June 30, 2015, 08:34:31 PM
 #27921

blocks full again with TPS unacceptably high --> unconf tx set ~ 3000, more than double normal.  pools taking defensive action.  when will Blockstream devs do something?:



Why do you call this "defensive" action?

when Chinese pools face a series of what they consider to be "large blocks", which in this case means full blocks as you can see from the data, they automatically switch to mining "header" blocks with 0 tx's during the time it takes to process all the tx's in the preceding large block.  this is b/c large blocks take a bit more time to process and check all the signatures so the argument goes that they can't afford to waste that precious time so for defensive purposed they just go ahead and start hashing  the next block with only the  "header" that in this case contain no tx's that might have included an invalid input from the preceding large block.

How about: When they see a new block, they immediately start mining based on that, with an empty transaction list. When they have removed the transactions in the last block from their own list of transactions to include, they mine with the new list. If a block is found quickly, it will be the empty block, else it will be a block with the new list.

You can see that the zero transaction blocks always come a short time after the previous. But they should not need minutes to establish a new list, so I am not sure.

Maybe some miner can chime in and say what really is going on.


your first paragraph was correct.

i'm not sure why the 0 tx blocks come so fast after the previous block.  i keep asking this.

it's the sigop checking of a large block, i believe, that takes the extra time.

Well my first paragraph suggested a reason. They need time to construct a new transaction list. When that is done, new transactions can more easily be added. The first list is the time consuming part.

Edit: The block finding is completely random. It is just as probable to find a block the first second, as after several minutes.


i know the probability is random.  so why has every_single_one i've seen always been within a minute or two?

Because they need to frenetically keep mining to cover investments and cost. They have to start mining before they have a list of transactions, and sometimes they find a block in that time interval. A miner could easily confirm or refute this, if one is in the room.
1481332806
Hero Member
*
Offline Offline

Posts: 1481332806

View Profile Personal Message (Offline)

Ignore
1481332806
Reply with quote  #2

1481332806
Report to moderator
1481332806
Hero Member
*
Offline Offline

Posts: 1481332806

View Profile Personal Message (Offline)

Ignore
1481332806
Reply with quote  #2

1481332806
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
tvbcof
Legendary
*
Online Online

Activity: 1988


View Profile
June 30, 2015, 08:35:00 PM
 #27922

Smart people have warned for a long time that zero-conf transactions are brittle.  If an 'industry' has built up around them, tough shit.

Serious question: are certain developers trying to get pushed out of their position? Is this all an elaborate warrant canary?

Employing those kinds of tactics means they become the damage around which the rest of Bitcoin will route.

Not exactly sure what you are getting at, but on one of these threads I posited that Gavin's recent actions with XT might actually have been something of a way of bowing out of something he didn't really want to be a part of.  A lot of people in a lot of spheres seemed to almost litterally have their jaws agape at what he was proposing and how.

From your text I sort of sense that you are wondering the same thing.  Not sure who you see as possibly taking such action though.  One way or another, good eyes!


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:41:55 PM
 #27923

that said I was wondering if another thing we could do is limiting max tx size. Did you rember that no more than a one or two months ago Peter Todd said that chain someone put an entire book on the blockchain?

maybe not an absolute limit but a progressive fee per kb... just a thougth.

can you explain the technicalities of that attack?

was it only possible b/c of p2sh?  also, did it only involve a non standard tx?  if so, isn't that only something that a miner could include into a block he self generates?  and why haven't we seen widespread usage of that attack if it's so effective that we have to worry about it?

nothing special actually, borrowing from here http://bitcoin.stackexchange.com/a/25292

Quote
There is a maximum standard transaction size since Bitcoin 0.8.2 of 100k per transaction.

There are a number of other limits that influence the validation and propagation of a transaction though. Specifically:

A block is limited to 20000 signature verifications.
The block itself can't be larger than 1Mb.
The standard Bitcoin client (Bitcoin Core / bitcoind) will refuse to relay transactions flagged as dust.
Enough fee should be included (0.0001 BTC/kb)

emph on standard is mine. not standard != invalid.

so there's not a direct limit to tx max size. I'm not expert enough to get all the details, though.

if memory serves in ptodd's git hub repo there's a python script that let you leverage those weak limits to fill the block chain with data (a lot of), maybe it even try to minimize the fee amount.

that said what I'm proposing is to increase the fee per KB progressively. e.g. the first 100 KB  will cost you X satoshi each, from 100 to 200 X*2 etc etc

you could use  whatever's monotonic increasing function you see fit.

but maybe I'm too naive and this is wishful thinking, maybe as soon as the block space will become more scarce the market will take care of the problem automatically



so b/c a book size tx is non-std, the only way to get it into a block is for a miner to self mine it into his own block.  and, in today's situation, if a pool miner operator is caught doing that on a regular basis, his constituent hashing miners would leave him en masse.

therefore, this isn't a problem long run.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 08:43:35 PM
 #27924

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a perfectly safe manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

Very clear explanation, rocks. 

Odalv, stop, please!
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 30, 2015, 08:46:49 PM
 #27925

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I'll broadcast 2 (or even 10) transactions to different nodes(and services) at same time  and you cannot know what transacion was FIRST.
I can make it harder if I'll brodcast transactions just after block is found ... or DDOS you during this time

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a "safe enough" manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

This is exactly what I think about you. You are spreading nonsense after nonsense. You are living in ideal/happy world where
 - there is not cheating
 - there are not governments like in china, russia ... (the one in USA are not using CIA, FBI .. to control citiziens)
 - there are not terrorists
 - only bitcoin happy community exists MtGox, Pirate40 ... :-)
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 30, 2015, 08:55:32 PM
 #27926

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a perfectly safe manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

Very clear explanation, rocks. 

Odalv, stop, please!

OK, I agree with you ( I'm tired :-), and I believe readers are not stupid )
1. Zero confirmed transactions, are the safest way how to transact with bitcoin.  100% security is confirmed
2. The more mining costs the more miners will mine.
3. The bigger blocks are the less spam.
4. ... another pearls :-)
sickpig
Legendary
*
Offline Offline

Activity: 1106


View Profile
June 30, 2015, 08:59:09 PM
 #27927

so b/c a book size tx is non-std, the only way to get it into a block is for a miner to self mine it into his own block.  and, in today's situation, if a pool miner operator is caught doing that on a regular basis, his constituent hashing miners would leave him en masse.

therefore, this isn't a problem long run.

I'd say that 100k is quite big and valid.

anyway I'll take a look at the "Infamous" book tx to see who mined it.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 30, 2015, 09:01:18 PM
 #27928

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I'll broadcast 2 (or even 10) transactions to different nodes(and services) at same time  and you cannot know what transacion was FIRST.
I can make it harder if I'll brodcast transactions just after block is found ... or DDOS you during this time

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a "safe enough" manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

This is exactly what I think about you. You are spreading nonsense after nonsense. You are living in ideal/happy world where
 - there is not cheating
 - there are not governments like in china, russia ... (the one in USA are not using CIA, FBI .. to control citiziens)
 - there are not terrorists
 - only bitcoin happy community exists MtGox, Pirate40 ... :-)


So you have no counter argument to present or explanation on how to attack a well formed transaction beyond the one example I provided, and instead just bring tin foil hat nonsense to the table. Got it.
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 30, 2015, 09:04:52 PM
 #27929

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I'll broadcast 2 (or even 10) transactions to different nodes(and services) at same time  and you cannot know what transacion was FIRST.
I can make it harder if I'll brodcast transactions just after block is found ... or DDOS you during this time

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a "safe enough" manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

This is exactly what I think about you. You are spreading nonsense after nonsense. You are living in ideal/happy world where
 - there is not cheating
 - there are not governments like in china, russia ... (the one in USA are not using CIA, FBI .. to control citiziens)
 - there are not terrorists
 - only bitcoin happy community exists MtGox, Pirate40 ... :-)


So you have no counter argument to present or explanation on how to attack a well formed transaction beyond the one example I provided, and instead just bring tin foil hat nonsense to the table. Got it.

As I wrote.
1. Zero confirmed transactions, are the safest way how to transact with bitcoin.  100% security is confirmed
tvbcof
Legendary
*
Online Online

Activity: 1988


View Profile
June 30, 2015, 09:07:19 PM
 #27930


So you have no counter argument to present or explanation on how to attack a well formed transaction beyond the one example I provided, and instead just bring tin foil hat nonsense to the table. Got it.

As I wrote.
1. Zero confirmed transactions, are the safest way how to transact with bitcoin.  100% security is confirmed

Some people cannot take 'yes' for an answer.  What can ya do?


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 09:09:22 PM
 #27931

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a perfectly safe manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

Very clear explanation, rocks. 

Odalv, stop, please!

OK, I agree with you ( I'm tired :-), and I believe readers are not stupid )
1. Zero confirmed transactions, are the safest way how to transact with bitcoin.  100% security is confirmed
2. The more mining costs the more miners will mine.
3. The bigger blocks are the less spam.
4. ... another pearls :-)

actually, i have one last question.  if your simultaneous spending tx's were a viable attack, why aren't you rich by now?
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 30, 2015, 09:13:25 PM
 #27932

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a perfectly safe manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

Very clear explanation, rocks. 

Odalv, stop, please!

OK, I agree with you ( I'm tired :-), and I believe readers are not stupid )
1. Zero confirmed transactions, are the safest way how to transact with bitcoin.  100% security is confirmed
2. The more mining costs the more miners will mine.
3. The bigger blocks are the less spam.
4. ... another pearls :-)

actually, i have one last question.  if your simultaneous spending tx's were a viable attack, why aren't you rich by now?

Really did not realize till now that there are so many fools accepting ZCT. Thank you for your informations.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 30, 2015, 09:17:28 PM
 #27933

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.


I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I'll broadcast 2 (or even 10) transactions to different nodes(and services) at same time  and you cannot know what transacion was FIRST.
I can make it harder if I'll brodcast transactions just after block is found ... or DDOS you during this time

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a "safe enough" manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

This is exactly what I think about you. You are spreading nonsense after nonsense. You are living in ideal/happy world where
 - there is not cheating
 - there are not governments like in china, russia ... (the one in USA are not using CIA, FBI .. to control citiziens)
 - there are not terrorists
 - only bitcoin happy community exists MtGox, Pirate40 ... :-)


So you have no counter argument to present or explanation on how to attack a well formed transaction beyond the one example I provided, and instead just bring tin foil hat nonsense to the table. Got it.

As I wrote.
1. Zero confirmed transactions, are the safest way how to transact with bitcoin.  100% security is confirmed


And who here besides you has made the statement that zero confirm transactions are 100% secure, no one.

As Peter said they are shades of gray. Well formed zero confirm transactions are not absolute but pretty reliable, in the same manner that 1-confirm transactions are not absolute but even more reliable and so on.

It's only malformed zero confirm transactions that are explicitly not reliable, but as explained those are easy to spot on the P2P network (and yes even a P2P network with cheaters, terrorists, Russia and China)

You should be a consultant for Bitpay and Coinbase warning them of the dangers of ZCT and how they need to stop. I'm sure they will gladly benefit from your insights.  Roll Eyes
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 09:17:32 PM
 #27934

 Roll Eyes  thats 13000 unconf tx's

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 09:18:12 PM
 #27935

 Roll Eyes

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 09:19:49 PM
 #27936

 Roll Eyes

Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
June 30, 2015, 09:20:40 PM
 #27937

1. Zero confirmed transactions, are the safest way how to transact with bitcoin.  100% security is confirmed

No one is claiming that.  I'm claiming that:

   0-conf (+ RBF)   <   0-conf (as is)   <  1-conf   <   2-conf …

Where the symbol [ < ] means "less secure than."  Do you disagree with the above inequality?

If not, what is the benefit of purposely making 0-conf less secure?

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 30, 2015, 09:20:51 PM
 #27938

Roll Eyes



It was BTCChina Pool that only processed 81KB of transactions. If I was a miner on them I'd move to someone else.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 30, 2015, 09:22:04 PM
 #27939

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a perfectly safe manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

Very clear explanation, rocks. 

Odalv, stop, please!

OK, I agree with you ( I'm tired :-), and I believe readers are not stupid )
1. Zero confirmed transactions, are the safest way how to transact with bitcoin.  100% security is confirmed
2. The more mining costs the more miners will mine.
3. The bigger blocks are the less spam.
4. ... another pearls :-)

actually, i have one last question.  if your simultaneous spending tx's were a viable attack, why aren't you rich by now?

Really did not realize till now that there are so many fools accepting ZCT. Thank you for your informations.

and even if you didn't realize this, there have probably been on the order of thousands who have tried and failed with your attack.

thanks for the non answer.
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 30, 2015, 09:23:23 PM
 #27940

rock and cypherdoc please publish your list of services with zero confirmation transaction you provide.
I'm getting mad ...... I WANT TO BUY !!!
Pages: « 1 ... 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 [1397] 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 ... 1560 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!