Bitcoin Forum
July 25, 2017, 02:57:10 PM *
News: BIP91 seems stable: there's probably only slightly increased risk of confirmations disappearing. You should still prepare for Aug 1.
 
   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 ... 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 [1205] 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1936694 times)
Natalia_AnatolioPAMM
Full Member
***
Offline Offline

Activity: 154


View Profile
May 15, 2015, 03:13:40 PM
 #24081

Yeah I am a type A personality and a fighter. I hate to lose. I also talk too much for my own good. And all this ego noise in this thread is just a huge waste of time. My first posts were about technical and correcting incorrect statements. This caused a firestorm of egos and character assassination attempts.

I've been pointing out that you seem to be exhibiting the most ego-driven behavior around here. But the nature of one with a big ego is that they do not respond to feedback concerning their ego so the reaction will be aggressive.

What a shame. Your self-proclaimed superior intelligence is going to waste, because you package your messages in a way which makes it very hard to respond to the message itself (which is often obfuscated) and instead lends itself to focusing on your ego-mania. You'll mostly get other egos lashing out at you, further fueling your story about sub-par beta-males being jealous of your superiority, ignorance or trolling. We could have a useful discussion but instead it seems to me that in spite of your rhetoric that is not what primarily motivates you - instead you write lengthy posts focusing on your person, supposedly "proving" your superiority, demanding admiration and constructing negative feedback as admiration clothed in jealousy. No fun and no profit in that I fear. You cut yourself off from valuable feedback and we don't get anything useful out of the interaction either.

I have respect for many people frequenting this thread and posting material which makes me think and I am grateful for that. I have respect for you because of the same thing - your writings have made me think and research as well. That is why I care and keep pointing this out to you. If you really want to be useful and harvest your abilities for the advancement of common good, get off your high horse, stop making everything about yourself and talk to us like a decent human being.

Communication is possible only between equals

I disagree. From my pov, everybody here has ego issue to some extend. Anonymint just has a slight différent view of the situation worldwide. Maybe more desperatly cynical. But i value his inputs as much as others around here. On the end i think we all want the same: bitcoins success, pocket money, and a fairer world.

You're talking about TPTB, not Anonymint, I quite enjoined Anonymint'w posts in other threads. The boxing video inputs pushed the topic of Bitcoin out of my entertainment zone. On the leval of digital binary his signal to noise ratio was very low.

One's attention is the most valuable commodity today, approximately 50% of the cost of making a new car today is spent on getting your attention.

TPTB (no pun intended) would be a little more effective if he understood the value of attention.
Aren't they the same person/thing?

I also thought so
1500994630
Hero Member
*
Offline Offline

Posts: 1500994630

View Profile Personal Message (Offline)

Ignore
1500994630
Reply with quote  #2

1500994630
Report to moderator
1500994630
Hero Member
*
Offline Offline

Posts: 1500994630

View Profile Personal Message (Offline)

Ignore
1500994630
Reply with quote  #2

1500994630
Report to moderator
1500994630
Hero Member
*
Offline Offline

Posts: 1500994630

View Profile Personal Message (Offline)

Ignore
1500994630
Reply with quote  #2

1500994630
Report to moderator
Decentralized search
Search for products or services and get paid for it
pre-sale Token CAT
25 July 50% discount
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1500994630
Hero Member
*
Offline Offline

Posts: 1500994630

View Profile Personal Message (Offline)

Ignore
1500994630
Reply with quote  #2

1500994630
Report to moderator
1500994630
Hero Member
*
Offline Offline

Posts: 1500994630

View Profile Personal Message (Offline)

Ignore
1500994630
Reply with quote  #2

1500994630
Report to moderator
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 15, 2015, 03:45:20 PM
 #24082

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

Is this idle curiosity or important to you?  If important probably I could fork the satoshi client and instrument it.  But then we'd have to collect data, etc. Its a medium time length project.

WRT TPTB/Anonymint, I vote that we put the speculation and constructive advice to bed at this point (I think he's heard enough), and rely on volunteers to very selectively quote and respond to his few information-filled bitcoin-related sentences.

sickpig
Legendary
*
Offline Offline

Activity: 1176


View Profile
May 15, 2015, 03:48:43 PM
 #24083

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

https://blockchain.info/en/unconfirmed-transactions


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

Activity: 756



View Profile
May 15, 2015, 03:58:11 PM
 #24084

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

https://blockchain.info/en/unconfirmed-transactions



I have glanced over that page a few times, and it seems, when it is high (4000 tx or more), it is filled with transactions that are never going to be included; dust, and zero fee transactions that should have a fee due to size and output age. Logically, when blocks are not full, the queue of valid transactions should be zero. I think we will not see a long list of valid unconfirmed transactions before we are quite close to the block size limit on a 24 hour basis.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 15, 2015, 04:05:07 PM
 #24085

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

Is this idle curiosity or important to you?  If important probably I could fork the satoshi client and instrument it.  But then we'd have to collect data, etc. Its a medium time length project.

i ask b/c of this bloated block attack being floated around.

we know that full nodes have unconf tx sets that correspond by somewhere over 90%; which is why IBLT could work to communicate across the network that a new block has been solved.  the ppl who argue against raising the 1MB cap say that an attacker could create these bloated blocks to torment small miners.  the question is, where would they get the extra tx's to construct this bloat?  from the unconf tx set or would they have to construct them themselves at considerable cost?  to answer this, it would be helpful to know the extent to which the unconf tx set gets cleared out every 10 min per block and the absolute size of the set so as to determine how many unconf tx's are left over that could be used in such an attack.

if i look at my 4 full nodes memory use, it's averaging around 200MB, but with around 500-600MB VSwap.  as i understand it, VSwap is to be considered a form of memory use so the total is around 800MB, which is consistent across my nodes:

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 15, 2015, 04:09:03 PM
 #24086

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

https://blockchain.info/en/unconfirmed-transactions



2MB, not much.  thus, it appears an attacker would have to construct and broadcast all his own fake or withheld tx's to try and perform this bloated block attack which, imo, is way too expensive and risky even though he would be paying himself his own tx fees.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 15, 2015, 04:23:51 PM
 #24087

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

https://blockchain.info/en/unconfirmed-transactions



I have glanced over that page a few times, and it seems, when it is high (4000 tx or more), it is filled with transactions that are never going to be included; dust, and zero fee transactions that should have a fee due to size and output age. Logically, when blocks are not full, the queue of valid transactions should be zero. I think we will not see a long list of valid unconfirmed transactions before we are quite close to the block size limit on a 24 hour basis.



that's even stronger evidence against this attack.

if the available unconf tx's are mostly invalid b/c of dust limits or being non-std, then those couldn't be included in such a bloated block.
Erdogan
Hero Member
*****
Offline Offline

Activity: 756



View Profile
May 15, 2015, 04:29:10 PM
 #24088

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

https://blockchain.info/en/unconfirmed-transactions



I have glanced over that page a few times, and it seems, when it is high (4000 tx or more), it is filled with transactions that are never going to be included; dust, and zero fee transactions that should have a fee due to size and output age. Logically, when blocks are not full, the queue of valid transactions should be zero. I think we will not see a long list of valid unconfirmed transactions before we are quite close to the block size limit on a 24 hour basis.



that's even stronger evidence against this attack.

if the available unconf tx's are mostly invalid b/c of dust limits or being non-std, then those couldn't be included in such a bloated block.

Well they are valid in the sense that the outputs exist and the signatures are correct, so an attacking miner could just include them all. Not that it concerns me.

Rant: in the beginning, I had the blockchain page up at all times, a bit concerned when there was no new block in an our or so. Not any more Smiley /Rant'

sickpig
Legendary
*
Offline Offline

Activity: 1176


View Profile
May 15, 2015, 04:35:27 PM
 #24089

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

https://blockchain.info/en/unconfirmed-transactions



I have glanced over that page a few times, and it seems, when it is high (4000 tx or more), it is filled with transactions that are never going to be included; dust, and zero fee transactions that should have a fee due to size and output age. Logically, when blocks are not full, the queue of valid transactions should be zero. I think we will not see a long list of valid unconfirmed transactions before we are quite close to the block size limit on a 24 hour basis.



that's even stronger evidence against this attack.

if the available unconf tx's are mostly invalid b/c of dust limits or being non-std, then those couldn't be included in such a bloated block.

Go to statoshi.info and look at "tx and blocks" section to have an idea of the trend

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
May 15, 2015, 04:42:56 PM
 #24090

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

https://blockchain.info/en/unconfirmed-transactions



2MB, not much.  thus, it appears an attacker would have to construct and broadcast all his own fake or withheld tx's to try and perform this bloated block attack which, imo, is way too expensive and risky even though he would be paying himself his own tx fees.

Well to be fair, the reason why we don't see this attack is because with the 1MB limit it is not possible to pull off. If BTCGuild started to do this, they could only take 3% of the blocks to 1MB, which is immaterial.

I think it would technically be very easy for a pool/miner to add a huge number of transactions into a block. For every address they have with 1BTC, they could create 10,000 transactions with 0.0001 fee each  (which they receive back in the coinbase transaction) by simply creating a chain of transactions in rapid succession. With 100BTC, they cloud create 1M transactions at zero cost because they would only include the transactions in their own block and recover the fees.

In the real world though, a pool could only do this a few times before miners would abandon them en mass, destroying the pool's business in the process. So it seems unlikely

At large solo miner with maybe 0.1% or 0.3% of the hash rate could start to inject very large 1GB blocks every 200 or 400 blocks or so, but in that case I could very easily see the rest of the pools agreeing to ignore those massive blocks. And even if they didn't coordinate to ignore them, the large blocks would propagate so slowly they might not be included anyway. (The attack requires transmitting a full block since Gavin's IBLT wouldn't help here).

Another way to address the issue of one or two rouge pools making large blocks, is to set a floating blocksize cap that resets with each difficulty adjustment and is based on an average of the last x number of blocks plus some overhead. Now to implement the attack an attacker would need to create false transactions that everyone mines on to bring up the average, but this would become too expensive since the fees would be lost to other miners.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 15, 2015, 04:48:06 PM
 #24091

I disagree. From my pov, everybody here has ego issue to some extend. Anonymint just has a slight différent view of the situation worldwide. Maybe more desperatly cynical. But i value his inputs as much as others around here. On the end i think we all want the same: bitcoins success, pocket money, and a fairer world.

At a basic level, we all are here because we believe the current system is broken, that most others are wrong,  and that we know why and know of a better system (Bitcoin or some other form of sound money). It takes a certain amount of ego to take on that view of the world.

The fact that we are right in knowing that Bitcoin is a better system, is immaterial. It takes a large amount of Ego to believe you are right and the vast majority are wrong.
Erdogan
Hero Member
*****
Offline Offline

Activity: 756



View Profile
May 15, 2015, 05:03:37 PM
 #24092

I disagree. From my pov, everybody here has ego issue to some extend. Anonymint just has a slight différent view of the situation worldwide. Maybe more desperatly cynical. But i value his inputs as much as others around here. On the end i think we all want the same: bitcoins success, pocket money, and a fairer world.

At a basic level, we all are here because we believe the current system is broken, that most others are wrong,  and that we know why and know of a better system (Bitcoin or some other form of sound money). It takes a certain amount of ego to take on that view of the world.

The fact that we are right in knowing that Bitcoin is a better system, is immaterial. It takes a large amount of Ego to believe you know better than most others.

I'd like to diffuse that a bit: We know it is a better system, because we know the economics of sound money, the cryptography, the computer security and a few special things we have learnt from the whole bitcoin discourse. So, when someone here says that NN does not understand money, even if it is an academic with a life long career in research, writing books, talking to conferences, having had multiple high level jobs and even an economic prize from the swedish central bank in memory of Alfred Nobel, he does not necessarily have a big ego, but rather the courage to say what he knows to be right and unafraid to be coerced (by display of power) into holding back. And, not having a stake in academia (and being anonymous) helps.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2324



View Profile
May 15, 2015, 05:19:52 PM
 #24093

At large solo miner with maybe 0.1% or 0.3% of the hash rate could start to inject very large 1GB blocks every 200 or 400 blocks or so, but in that case I could very easily see the rest of the pools agreeing to ignore those massive blocks. And even if they didn't coordinate to ignore them, the large blocks would propagate so slowly they might not be included anyway. (The attack requires transmitting a full block since Gavin's IBLT wouldn't help here).

ah, of course. IBLT doesn't help the rogue miner because his transactions haven't been broadcast. And he can't broadcast because then he risks losing the tx fees. I had overlooked that.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
kodtycoon
Hero Member
*****
Offline Offline

Activity: 672



View Profile
May 15, 2015, 05:35:37 PM
 #24094

all you math heads and CS guys will find this a very interesting read i think.. lost of ground breaking tech and lots of examples of algorithms etc.. i dont understand the maths at all so any expert input into this would be appreciated. Smiley

https://drive.google.com/file/d/0B7wAe2jt1MMzYVJhUUFnMHQxZ1U/view?usp=sharing

  Blog \ Telegram \ /evxslack]Slack
WHITEPAPER


                     ███████████████
                ██████████████████████████
             ███████████           ██████████
          ████████                       ███████
        ███████                             ███████
      ██████                                  ██████
     █████                                      ██████
    █████                                         █████
   ████                                            █████
  ████                                              █████
 █████                                               █████
█████                               ██████            █████
████                               ██    ██           █████
████        ███████               ███    ███           ████
████       ███    ██            ██████████████         ████
████      ████   █████        ██████       █████       ████
████    ████████████████    ██████           █████     ████
████  ██████        ██    ██████               █████  █████
██████████              ██████                   █████████
 ███████              ██████                       ███████
  ████              ██████                          █████
  ██              ██████                           █████
                ██████                            █████
              ██████                            ██████
            ██████                            ██████
          ██████                            ███████
          █████████                     █████████
             ███████████           ███████████
                 █████████████████████████
                      ███████████████
EVEREX


██████████
 ██████████
  ██████████

   ██████████
    ██████████
     ██████████
      ██████████
       ██████████
        ██████████
Creating a Global Inclusive Economy with Blockchain-
     Powered Microfinance and Remittances Services
████████████████████████████████████████████████████████████████████████


██████████
 ██████████
  ██████████

   ██████████
    ██████████
     ██████████
      ██████████
       ██████████
        ██████████
Tokensale - July 24th
         ERC20 TOKENS
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 15, 2015, 06:08:59 PM
 #24095

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

https://blockchain.info/en/unconfirmed-transactions



2MB, not much.  thus, it appears an attacker would have to construct and broadcast all his own fake or withheld tx's to try and perform this bloated block attack which, imo, is way too expensive and risky even though he would be paying himself his own tx fees.

Well to be fair, the reason why we don't see this attack is because with the 1MB limit it is not possible to pull off. If BTCGuild started to do this, they could only take 3% of the blocks to 1MB, which is immaterial.

I think it would technically be very easy for a pool/miner to add a huge number of transactions into a block. For every address they have with 1BTC, they could create 10,000 transactions with 0.0001 fee each  (which they receive back in the coinbase transaction) by simply creating a chain of transactions in rapid succession. With 100BTC, they cloud create 1M transactions at zero cost because they would only include the transactions in their own block and recover the fees.

In the real world though, a pool could only do this a few times before miners would abandon them en mass, destroying the pool's business in the process. So it seems unlikely

At large solo miner with maybe 0.1% or 0.3% of the hash rate could start to inject very large 1GB blocks every 200 or 400 blocks or so, but in that case I could very easily see the rest of the pools agreeing to ignore those massive blocks. And even if they didn't coordinate to ignore them, the large blocks would propagate so slowly they might not be included anyway. (The attack requires transmitting a full block since Gavin's IBLT wouldn't help here).

Another way to address the issue of one or two rouge pools making large blocks, is to set a floating blocksize cap that resets with each difficulty adjustment and is based on an average of the last x number of blocks plus some overhead. Now to implement the attack an attacker would need to create false transactions that everyone mines on to bring up the average, but this would become too expensive since the fees would be lost to other miners.


I was assuming the unconfirmed TX set to stay relatively the same size if the cap was lifted.

First off, you can't take a 1BTC address and create 10000 zero balance outputs  with 0.0001BTC fees. They are invalid and wouldn't be accepted by the rest of network.

Second, even if the attacking miner constructs  non zero output  TX's, he  can't just spring this block onto the network filled with those TX's if the network nodes haven't heard about them beforehand. They will reject  the bloated block since they don't recognize any of the content.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 15, 2015, 06:31:47 PM
 #24096

Russia back onboard apparently:

http://www.reddit.com/r/Bitcoin/comments/362f12/bitcoin_websites_unblocked_in_russia_court_was_won/
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 15, 2015, 07:22:12 PM
 #24097

Let me ask again.

Does anyone know the average number of unconfirmed TX's that exist in mempool at any given time, the average size in MB (i know <1) and what % of them get cleared into a block every 10 minutes or so?

https://blockchain.info/en/unconfirmed-transactions



2MB, not much.  thus, it appears an attacker would have to construct and broadcast all his own fake or withheld tx's to try and perform this bloated block attack which, imo, is way too expensive and risky even though he would be paying himself his own tx fees.

Well to be fair, the reason why we don't see this attack is because with the 1MB limit it is not possible to pull off. If BTCGuild started to do this, they could only take 3% of the blocks to 1MB, which is immaterial.

I think it would technically be very easy for a pool/miner to add a huge number of transactions into a block. For every address they have with 1BTC, they could create 10,000 transactions with 0.0001 fee each  (which they receive back in the coinbase transaction) by simply creating a chain of transactions in rapid succession. With 100BTC, they cloud create 1M transactions at zero cost because they would only include the transactions in their own block and recover the fees.

In the real world though, a pool could only do this a few times before miners would abandon them en mass, destroying the pool's business in the process. So it seems unlikely

At large solo miner with maybe 0.1% or 0.3% of the hash rate could start to inject very large 1GB blocks every 200 or 400 blocks or so, but in that case I could very easily see the rest of the pools agreeing to ignore those massive blocks. And even if they didn't coordinate to ignore them, the large blocks would propagate so slowly they might not be included anyway. (The attack requires transmitting a full block since Gavin's IBLT wouldn't help here).

Another way to address the issue of one or two rouge pools making large blocks, is to set a floating blocksize cap that resets with each difficulty adjustment and is based on an average of the last x number of blocks plus some overhead. Now to implement the attack an attacker would need to create false transactions that everyone mines on to bring up the average, but this would become too expensive since the fees would be lost to other miners.


I was assuming the unconfirmed TX set to stay relatively the same size if the cap was lifted.

First off, you can't take a 1BTC address and create 10000 zero balance outputs  with 0.0001BTC fees. They are invalid and wouldn't be accepted by the rest of network.

You start with 1BTC and send 0.9999BTC to a new address with a 0.0001BTC fee -> then 0.9998BTC -> 0.9997BTC and so on until you have created a chain of 10,000 transactions, each paying a 0.0001BTC fee. This is a chain of valid transactions.

Since these fees are recovered by yourself, you don't mind paying them and can do this over and over and over again. For every 100BTC that you control you can create 1M transactions in every block you mine with this attack.

Second, even if the attacking miner constructs  non zero output  TX's, he  can't just spring this block onto the network filled with those TX's if the network nodes haven't heard about them beforehand. They will reject  the bloated block since they don't recognize any of the content.

Blocks can include any transaction, even ones that network nodes haven't heard about. Today nodes receive transactions a minimum of 2 times today, once as it is broadcast, and a 2nd time in the block it is picked up in.

The entire reason for Gavin's IBLT proposal is to eliminate this wastefulness and take advantage of the fact nodes already have heard of most of the blocks.

However even after IBLT is implemented you can still include unannounced transactions in blocks. You just would have to send the whole block and not the IBLT diff.
Erdogan
Hero Member
*****
Offline Offline

Activity: 756



View Profile
May 15, 2015, 07:22:31 PM
 #24098


The discussion on reddit was about this being reported in the main stream media.

The answer is, if it can be used to smear Russia, it will be reported, if not, it will not be reported (I hope I am wrong).
Peter R
Legendary
*
Offline Offline

Activity: 1036



View Profile
May 15, 2015, 07:27:03 PM
 #24099

I was assuming the unconfirmed TX set to stay relatively the same size if the cap was lifted.

First off, you can't take a 1BTC address and create 10000 zero balance outputs  with 0.0001BTC fees. They are invalid and wouldn't be accepted by the rest of network.

Second, even if the attacking miner constructs  non zero output  TX's, he  can't just spring this block onto the network filled with those TX's if the network nodes haven't heard about them beforehand. They will reject  the bloated block since they don't recognize any of the content.

There's a difference between non-standard transactions and invalid transactions.  Non-standard transactions are a subset of valid transactions. Examples of non-standard transactions are TXs with outputs less than the dust limit or TXs with insufficient fees; such transactions may still be valid, however.  

Clients do not relay nonstandard transactions, nor accept them into mempool, but will nonetheless accept a solved block that contains them (provided each TX in the block is still valid).    Example of blocks full of nonstandard (and pointless) transactions are Block #309657 and Block #309740.  They each contain thousands of 1 satoshi dust outputs that will pollute the UTXO set for a long time!

Code:
BLOCK #309740:  10,486 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================                      
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16 749

BLOCK #309657: 7,490 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================  
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651 749

A miner can fill a block full of nonsense transactions very easily.  

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

Activity: 1153


View Profile
May 15, 2015, 07:38:41 PM
 #24100

I was assuming the unconfirmed TX set to stay relatively the same size if the cap was lifted.

First off, you can't take a 1BTC address and create 10000 zero balance outputs  with 0.0001BTC fees. They are invalid and wouldn't be accepted by the rest of network.

Second, even if the attacking miner constructs  non zero output  TX's, he  can't just spring this block onto the network filled with those TX's if the network nodes haven't heard about them beforehand. They will reject  the bloated block since they don't recognize any of the content.

There's a difference between non-standard transactions and invalid transactions.  Non-standard transactions are a subset of valid transactions. Examples of non-standard transactions are TXs with outputs less than the dust limit or TXs with insufficient fees; such transactions may still be valid, however.  

Clients do not relay nonstandard transactions but will accept a solved block that contains them (provided each TX in the block is still valid).    Example of blocks full of nonstandard (and pointless) transactions are Block #309657 and Block #309740.  They each contain thousands of 1 satoshi dust outputs that will pollute the UTXO set for a long time!

Code:
BLOCK #309740:  10,486 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================                      
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2b6112e73cbe0937a1b60c9abfc4c2ca6e26b2612c90ec598b1cd28787a553e 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5e5d17901378b8835861d8cc0df2b5f9bf3c86759c3821f96470cd852344d799 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b2bf7525618ed5402024d5bff6f477a2093965d3f11ececbc2b6a9b5bbe1f5d5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3df8f4a7e06486bb3b0700935a16fc6d4fad397dcb6c88b9c4b6a7453301aa54 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ae05ddfc8aa206b213c71ec0e96723dcd4ff03a71ca76b469d225d1c60d9e262 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f75b455b4df94bcdcd54985b4aeea9948d2a1dca0f63c65b85ad2d941050c5cf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z ee61b911610f66f539832699fbbf4ab3955c8bd5ad0cfa570ff500dedcde5bf8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a22186cbcf82cac66da17183209f20f76088934c931bec131fe71ad2f250e8f8 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 0469286403543b7d794fe52661135a80142c47ac541793c703fd637a4e9dc0bf 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z a71dc9abd8bae377b661b0c288222acf2ab62fc7bf96b0bab2dd5354fbc91643 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f437d94c1cfe818c44f4505f3e6506839113ec747d815a867e953a4164276047 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z eb95d902eb841ce23c9c1466e010cbb05d43d1c248376440f9dd56ee1bc8b3e5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z b62416ceb3453d6dcba95213e4e222915438a4b70eba37e09099110b20be0d52 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z f3aba1c064e9c9a1d49db3bce42c07c184a0b329366994000fa49f0bc8f3ba16 749

BLOCK #309657: 7,490 DUST OUTPUTS
        ADDRESS SENT FROM                                            TX HASH                              N_OUTPUTS    
===================================================================================================================  
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 2e7fdb43e2a0fe17cfe2d283a2da4d375204700aef4bf2c31056125f4383b121 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3d1105d7c2cd36705b2163fa2d0f74973377467aefea72156a30444f330acf71 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 5c4e56943f3128629ebecb41f5916bd7bc1dceaccc37f29e59c385464f2bf558 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 536adfb745ffaa8c1fb698414475f5ca7d82846eadd912cfe0a76045d78c3198 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 45c7544374e88de47d9be2e3e100f4aa10aafd9469c4dba8d55a870f83c312ab 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z e7ae2378a44a940a8c872a63e43fa67c5a023df4df3f9ca8011611422fc2861c 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z d864e3cc07dc79f221bd91210b274e136159ccbb5c9eafad906d9d08c5558ce5 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 3dedbc086d5cfc81bd3614a1b3fab1bb4d73d8982d9552e811f84f0118a1fc12 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 7337d7ac353a9283c65a1ab99d28f97997784a0fb26d0dc0b59f2fa2556c4460 749
1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z 634a7fdcba3fe91da07f44e6b9bee1c659cbfca27076bd8b61984d062c071651 749

A miner can fill a block full of nonsense transactions very easily.  

Good point on the inclusion of non-standard but valid transactions. What I outlined just included standard & valid transactions. What you outlined is how much further an attacker could push this, here 1BTC could turn into 100M satoshi dush outputs....

On the UTXO topic, the distribution of balances here

http://bitcoinrichlist.com/charts/bitcoin-distribution-by-address?atblock=350000

shows that 96.97% of addresses contain less than 0.001 BTC. Now these are address totals, any analysis of UTXO outputs would show that more than 96.97% of UTXO outputs contain less than 0.001BTC.

I think this shows that the UTXO is already vastly populated by dust nonsense that simply sits around. If UTXO size becomes an issue any intelligent implementation could easily swap these out to a lower tier of storage. Most of this dust will never be spent simply because you'd have to pay more in fees than the output is worth, spending them is literally burning money.
Pages: « 1 ... 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 [1205] 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 ... 1558 »
  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!