<<  >> (p.11)
    Author Topic: Are we stress testing again?  (Read 33245 times)

    • turvarya
    Hero Member
    *****
    Offline Offline

    Activity: 714
    Merit: 502


    View Profile
    July 09, 2015, 10:01:27 AM
     #201
    Quote from: sidhujag on July 09, 2015, 07:39:11 AM
    Quote from: JorgeStolfi on July 09, 2015, 06:16:15 AM
    Quote from: sidhujag on July 08, 2015, 11:30:31 PM
    With an increase in blocksize and fees decreasing as a result, spam attacks will only get bigger not smaller.

    An increase in the blocksize LIMIT does not mean an increase in blocksize.

    An increase in block size will not reduce the fees.  The minimum fee is fixed by the relay nodes, and could (should, IMHO) be part of the 'consensus rules' so that the miners cannot raise or undercut it.

    A spam attack is effective only if it puts out more transactions per minute than the network can process.  With 1 MB block size limit, an attacker needs to issue 0.7 tx/s to create a backlog. With 1 US cent of fee per transaction, that would cost him only 25 dollars per hour.  If the max block size limit was 8 MB, the attacker would have to issue ~15 tx/s and spend ~500 USD/h.  So a bigger block size will make spam attacks a lot less likely (and will clear the backlog faster if they still were to occur).
    It's not fixed its driven by demand:

    "If blocks are 8MB, the fees will fall, therefore the cost of getting 1MB of spam on the blockchain will fall. Moving spam from the memepool (a temporary issue) to the UTXO (a permanent issue) is a bad idea. Increasing the blocksize makes the spam problem worse.
    Anyway in the medium run, if the blocksize goes to 8MB, spammers will NOT need to spend 8x more to flood blocks. The necessary fees to outbid normal users will be driven by the economic demand for genuine transactions, increasing the blocksize will not necessarly increase this threshold." Jonny1000

    Assumptions are our worsed Achilles heal.
    So, the assumption that fees will fall, when the max block size increases is our worst Achilles heel?
    Seriously, most people are just making a lot of assumption based on what they saw in a Meme.
    https://forum.bitcoin.com/
    New censorship-free forum by Roger Ver. Try it out.

  • Pathi (OP)
    Sr. Member
    ****
    Offline Offline

    Activity: 244
    Merit: 250



    View Profile
    July 09, 2015, 12:06:55 PM
     #202
    20 hours and still no confirmations...


    http://btc.blockr.io/tx/info/1073aeaad411ef4e6f375a0ec5511a39b4d2a932256833b32a438332fe1311bc

    Really frustrating.

  • favdesu
    Legendary
    *
    Offline Offline

    Activity: 1764
    Merit: 1000



    View Profile WWW
    July 09, 2015, 12:38:19 PM
     #203
    Quote from: Pathi on July 09, 2015, 12:06:55 PM
    20 hours and still no confirmations...


    http://btc.blockr.io/tx/info/1073aeaad411ef4e6f375a0ec5511a39b4d2a932256833b32a438332fe1311bc

    Really frustrating.

    but there's a confirmation Smiley at least your transaction cleared.

    better add a higher TX fee for the time being
    Bitcoin Experiment: Financial Freedom with Faucets?! Week 19

  • Pursuer
    Legendary
    *
    Offline Offline

    Activity: 1638
    Merit: 1163


    Where is my ring of blades...


    View Profile
    July 09, 2015, 01:01:28 PM
     #204
    this is getting really frustrating now. I had 2 transactions stuck for a whole day during this nonsense.

    the normal (standard) fee is no longer enough!
    Only Bitcoin

  • Pathi (OP)
    Sr. Member
    ****
    Offline Offline

    Activity: 244
    Merit: 250



    View Profile
    July 09, 2015, 01:07:18 PM
     #205
    Quote from: favdesu on July 09, 2015, 12:38:19 PM
    Quote from: Pathi on July 09, 2015, 12:06:55 PM
    20 hours and still no confirmations...


    http://btc.blockr.io/tx/info/1073aeaad411ef4e6f375a0ec5511a39b4d2a932256833b32a438332fe1311bc

    Really frustrating.

    but there's a confirmation Smiley at least your transaction cleared.

    better add a higher TX fee for the time being

    Yeah I see it now. Unfortunately I am the recipient of this transaction, so no control over fee. I hope Nicehash adjusts their fees today.

  • sidhujag
    Legendary
    *
    Offline Offline

    Activity: 2044
    Merit: 1005


    View Profile
    July 09, 2015, 02:18:21 PM
     #206
    Quote from: turvarya on July 09, 2015, 10:01:27 AM
    Quote from: sidhujag on July 09, 2015, 07:39:11 AM
    Quote from: JorgeStolfi on July 09, 2015, 06:16:15 AM
    Quote from: sidhujag on July 08, 2015, 11:30:31 PM
    With an increase in blocksize and fees decreasing as a result, spam attacks will only get bigger not smaller.

    An increase in the blocksize LIMIT does not mean an increase in blocksize.

    An increase in block size will not reduce the fees.  The minimum fee is fixed by the relay nodes, and could (should, IMHO) be part of the 'consensus rules' so that the miners cannot raise or undercut it.

    A spam attack is effective only if it puts out more transactions per minute than the network can process.  With 1 MB block size limit, an attacker needs to issue 0.7 tx/s to create a backlog. With 1 US cent of fee per transaction, that would cost him only 25 dollars per hour.  If the max block size limit was 8 MB, the attacker would have to issue ~15 tx/s and spend ~500 USD/h.  So a bigger block size will make spam attacks a lot less likely (and will clear the backlog faster if they still were to occur).
    It's not fixed its driven by demand:

    "If blocks are 8MB, the fees will fall, therefore the cost of getting 1MB of spam on the blockchain will fall. Moving spam from the memepool (a temporary issue) to the UTXO (a permanent issue) is a bad idea. Increasing the blocksize makes the spam problem worse.
    Anyway in the medium run, if the blocksize goes to 8MB, spammers will NOT need to spend 8x more to flood blocks. The necessary fees to outbid normal users will be driven by the economic demand for genuine transactions, increasing the blocksize will not necessarly increase this threshold." Jonny1000

    Assumptions are our worsed Achilles heal.
    So, the assumption that fees will fall, when the max block size increases is our worst Achilles heel?
    Seriously, most people are just making a lot of assumption based on what they saw in a Meme.
    The opposite.. Assuming they won't fall.

  • achow101
    Staff
    Legendary
    *
    Offline Offline

    Activity: 3794
    Merit: 7454


    Just writing some code


    View Profile WWW
    July 09, 2015, 02:22:34 PM
     #207
    Quote from: nerioseole on July 09, 2015, 05:59:16 AM
    Quote from: knightdk on July 09, 2015, 03:45:21 AM

    Quote from: nerioseole on July 09, 2015, 03:39:42 AM
    RAM.

    Restart the node and you delete all pending transactions and start from scratch!
    Doesn't work like that. You need everyone to shutdown and boot up at the same time. As long as one node is up, it will send all of the transactions it knows of to everyone.

    Agree to disagree?  

    My experience is that an upcoming node will only listen to new incoming tx relayed by the peers - it won't ask for the full outstanding list of standby tx from its peers. If I am incorrect, please provide me with the codebase.

    When I restart my node, my "getmempoolinfo" starts with 0, and then grows with time - not because I receive the full list of outstanding tx from my peers, but because it matches the rate of "fresh" incoming transactions.

    I have learned to do this by being an Electrum-Server.  I use to restart its Bitcoin daemon once a week, to get rid of the unconfirmed transactions that clogged the RAM  - this week, I am doing it daily.

    In a way, it is not bad, if everyone would do that, it would allow payers to resend their coins (which are still not included into a block) with a higher fee, without being discarded by the nodes as a "double spent".  
    I'm pretty sure that you will still end up with all of the transactions that are in the mempool anyways, or most of them. When your node receives a transaction, it will check its validity, and in order to do that, it must have its parent. If it doesn't have the parent, then it requests it from other nodes. And so on and so forth. If someone was spamming the network with the transactions go down a chain (e.g. A -> B -> C...) then your node will still get all of those transactions because it requires the parent to validate a transaction. Other spam where 1 parent has multiple children may not cause your mempool to fill up because it does not see all of the child transactions. However, once a transaction that consolidates all of the micro transactions into one address comes out, your node will still have to request all of those micro transactions and still fill up your mempool. So you will pretty much still have to get all of those transactions again from somewhere and fill up your mempool.
    Bitcoin Core contributor | Tip Me! | GitHub | GPG Key Fingerprint 0x17565732E08E5E41

  • Mikestang
    Legendary
    *
    Offline Offline

    Activity: 1274
    Merit: 1001



    View Profile
    July 09, 2015, 07:21:39 PM
     #208
    Quote from: JorgeStolfi on July 08, 2015, 07:37:34 PM
    the cost would be ~80 USD/h with 1 MB blocks,  ~850 USD/h with 8 MB blocks, and ~2100 USD/h with 20 MB blocks.

    Is that cost just the tx fees?  Because if you're sending transactions to yourself the only cost would be tx fee.  I didn't see this stated, so just wondering.

  • johnyj
    Legendary
    *
    Offline Offline

    Activity: 1988
    Merit: 1012


    Beyond Imagination


    View Profile
    July 09, 2015, 10:14:15 PM
     #209
    Quote from: Holliday on July 09, 2015, 04:56:48 AM
    Quote from: canth on July 09, 2015, 03:48:10 AM
    Quote from: nerioseole on July 09, 2015, 03:39:42 AM
    Quote from: favdesu on July 09, 2015, 03:37:53 AM
    mempool is at close 80mb and 95k transactions. what's the critical number for nodes to go down?
    RAM.

    Restart the node and you delete all pending transactions and start from scratch!

    Yep - you don't even have to restart the node - just kill and restart bitcoind. -*yeah, good point- as bitcoind starts up it requests transactions it missed*

    As far as the critical number goes, it's hard to say. bitcoind currently takes around 1GB on my linux node - presuming a lot of nodes have only 2GB, perhaps it would take 10X current or around 1m transactions in mempool to start causing serious problems?

    My node has been up without restart for over a week (so up for all these recent tests) and is connected to 60+ peers.

    getmempoolinfo

    {
    "size" : 2178,
    "bytes" : 2634223
    }

    According to task manager Bitcoin Core is using 500MB of RAM (slightly more than my web browser).

    Sup? Everyone here knows you can modify your fee rules to ignore transactions that you consider spam, right?

    Mine 1-week-uptime node's getmempoolinfo shows 5xxxx for size and 124xxxxxx for bytes, 5 minutes after a restart of the process, size become 1476 and bytes become 3xxxxxx, let's see what it will finally show, I guess after 6 hours it will catch up with the rest of the nodes
    Why bitcoin will appreciate forever: https://bt.irlbtc.com/view/277275.msg3244038#msg3244038

  • CohibAA
    Full Member
    ***
    Offline Offline

    Activity: 223
    Merit: 132



    View Profile WWW
    July 09, 2015, 10:33:58 PM
     #210
    Quote from: chmod755 on July 09, 2015, 10:19:52 PM
    I temporarily set the following options:

    Quote
    -minrelaytxfee=0.001 -limitfreerelay=0

    I'm avoiding transactions on the blockchain at the moment (mostly doing SEPA wires now...)

    Quote
    -limitfreerelay=<n>          Continuously rate-limit free transactions to <n>*1000 bytes per minute (default:15)

    minrelaytxfee=0.xxx and mintxfee=0.xxx will help if your node is lagging, for sure.


    I've read, but can't find the source right now that limitfreerelay shouldn't be set to 0, but instead to 1.  It's measured in kb allocated to free/high-priority transactions, and the claim was that setting to 0 would actually restore the default value (15 kb).

    Can anyone verify, either way?

  • zvs
    Legendary
    *
    Offline Offline

    Activity: 1694
    Merit: 1001



    View Profile WWW
    July 09, 2015, 10:37:20 PM
     #211
    Quote from: CohibAA on July 09, 2015, 10:33:58 PM
    Quote from: chmod755 on July 09, 2015, 10:19:52 PM
    I temporarily set the following options:

    Quote
    -minrelaytxfee=0.001 -limitfreerelay=0

    I'm avoiding transactions on the blockchain at the moment (mostly doing SEPA wires now...)

    Quote
    -limitfreerelay=<n>          Continuously rate-limit free transactions to <n>*1000 bytes per minute (default:15)

    minrelaytxfee=0.xxx and mintxfee=0.xxx will help if your node is lagging, for sure.


    I've read, but can't find the source right now that limitfreerelay shouldn't be set to 0, but instead to 1.  It's measured in kb allocated to free/high-priority transactions, and the claim was that setting to 0 would actually restore the default value (15 kb).

    Can anyone verify, either way?

    kind of, yeah.  though if the problem is downstream bandwidth, you'll be out of luck, even with those settings

    and I use these:

    mintxfee=0.0001
    minrelaytxfee=0.0001
    limitfreerelay=0
    blockminsize=0
    blockprioritysize=0

    oh, and here is an example of what I mean, re: this is what your peer list looks like when everyone else is flooding you with dust transactions

    Code:
      {
        "id": 37,
        "addr": "ipv6:8333",
        "addrlocal": "gangnam",
        "services": "0000000000000003",
        "lastsend": 1436481618,
        "lastrecv": 1436481618,
        "bytessent": 1785478,
        "bytesrecv": 23670587,
        "conntime": 1436477662,
        "timeoffset": 0,
        "pingtime": 0.06790500,
        "version": 70003,
        "subver": "/Bitcoin XT:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364599,
        "synced_blocks": 364599,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 38,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481619,
        "bytessent": 2207672,
        "bytesrecv": 14434904,
        "conntime": 1436477663,
        "timeoffset": -2,
        "pingtime": 0.36456500,
        "version": 70002,
        "subver": "/Satoshi:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364608,
        "synced_blocks": 364608,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 41,
        "addr": "ipv6:8333",
        "addrlocal": "gangnam",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481619,
        "bytessent": 2000115,
        "bytesrecv": 17358323,
        "conntime": 1436477663,
        "timeoffset": 0,
        "pingtime": 0.11342300,
        "version": 70002,
        "subver": "/Satoshi:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364607,
        "synced_blocks": 364607,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 42,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481619,
        "bytessent": 1037411,
        "bytesrecv": 17674962,
        "conntime": 1436477663,
        "timeoffset": 0,
        "pingtime": 0.05954100,
        "version": 70002,
        "subver": "/Satoshi:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364608,
        "synced_blocks": 364608,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 43,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481618,
        "bytessent": 1033799,
        "bytesrecv": 17991886,
        "conntime": 1436477663,
        "timeoffset": 0,
        "pingtime": 0.11224400,
        "version": 70002,
        "subver": "/Satoshi:0.10.1/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364608,
        "synced_blocks": 364608,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 44,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481619,
        "bytessent": 3983425,
        "bytesrecv": 16857389,
        "conntime": 1436477663,
        "timeoffset": -1,
        "pingtime": 0.11399700,
        "version": 70002,
        "subver": "/Satoshi:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364608,
        "synced_blocks": 364608,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 45,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481619,
        "bytessent": 2155391,
        "bytesrecv": 17652045,
        "conntime": 1436477663,
        "timeoffset": 10,
        "pingtime": 0.36462200,
        "version": 70002,
        "subver": "/Satoshi:0.10.1/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364607,
        "synced_blocks": 364607,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 46,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481619,
        "bytessent": 2229207,
        "bytesrecv": 17663426,
        "conntime": 1436477664,
        "timeoffset": 7,
        "pingtime": 0.38534900,
        "version": 70002,
        "subver": "/Satoshi:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364608,
        "synced_blocks": 364608,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 47,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481619,
        "bytessent": 4674688,
        "bytesrecv": 17627298,
        "conntime": 1436477664,
        "timeoffset": -13,
        "pingtime": 0.83111700,
        "version": 70002,
        "subver": "/Satoshi:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364601,
        "synced_blocks": 364601,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 48,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481618,
        "bytessent": 2846248,
        "bytesrecv": 18435766,
        "conntime": 1436477664,
        "timeoffset": -4,
        "pingtime": 0.17268700,
        "version": 70002,
        "subver": "/Satoshi:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364599,
        "synced_blocks": 364599,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 49,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481619,
        "bytessent": 1014515,
        "bytesrecv": 17733905,
        "conntime": 1436477665,
        "timeoffset": -23,
        "pingtime": 0.16491500,
        "version": 70002,
        "subver": "/Satoshi:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364608,
        "synced_blocks": 364608,
        "inflight": [
        ],
        "whitelisted": false
      },
      {
        "id": 51,
        "addr": "ipv4:8333",
        "addrlocal": "style",
        "services": "0000000000000001",
        "lastsend": 1436481618,
        "lastrecv": 1436481619,
        "bytessent": 1059026,
        "bytesrecv": 15543199,
        "conntime": 1436477665,
        "timeoffset": -1,
        "pingtime": 0.09709600,
        "version": 70002,
        "subver": "/Satoshi:0.10.2/",
        "inbound": false,
        "startingheight": 364599,
        "banscore": 0,
        "synced_headers": 364608,
        "synced_blocks": 364608,
        "inflight": [
        ],
        "whitelisted": false

    client runtime: about 60-65 minutes

  • CohibAA
    Full Member
    ***
    Offline Offline

    Activity: 223
    Merit: 132



    View Profile WWW
    July 09, 2015, 10:51:34 PM
     #212
    Quote from: chmod755 on July 09, 2015, 10:44:45 PM

    0 means 0, only if you don't set it the default setting is 15:

    ...



    Perfect, thank you.

  • CohibAA
    Full Member
    ***
    Offline Offline

    Activity: 223
    Merit: 132



    View Profile WWW
    July 09, 2015, 10:59:46 PM
     #213
    Quote from: zvs on July 09, 2015, 10:37:20 PM

    kind of, yeah.  though if the problem is downstream bandwidth, you'll be out of luck, even with those settings


    Understood.  I am just curious; how would a downstream bandwidth problem present itself?  Wouldn't you just receive less bytes/second, which wouldn't actually slow down the local server?  Maybe you mean something different than ISP level downstream?

  • cakir
    Legendary
    *
    Offline Offline

    Activity: 1274
    Merit: 1001


    ★ BitClave ICO: 15/09/17 ★


    View Profile WWW
    July 09, 2015, 11:04:40 PM
     #214
    I bet first this guy (https://bitcointalk.org/index.php?action=profile;u=154254) (Yes, TKeenan) will come here and post something like that "Hey, let's use bigger blocks, don't you see we need it right now!"

    I'm still thinking Gavin is doing such spamming.

    Also how the hell is that possible?
    This tx broadcasted (spammed network) and  get accepted immediately; https://blockchain.info/tx/5f475e567548232d3b9f395b941c2ca8584df68492bd586937cd8d08f96c30e7
    It's outputs are lower than the min limit...

                      ,'#██+:                 
                  ,█████████████'             
                +██████████████████           
              ;██████████████████████         
             ███████:         .███████`       
            ██████               ;█████'      
          `█████                   #████#     
          ████+                     `████+    
         ████:                        ████,   
        ████:    .#              █     ████   
       ;███+     ██             ███     ████  
       ████     ███'            ███.    '███, 
      +███     #████           ,████     ████ 
      ████     █████ .+██████: █████+    `███.
     ,███     ███████████████████████     ████
     ████     ███████████████████████'    :███
     ███:    +████████████████████████     ███`
     ███     █████████████████████████`    ███+
    ,███     ██████████████████████████    #███
    '███    '██████████████████████████    ;███
    #███    ███████████████████████████    ,███
    ████    ███████████████████████████.   .███
    ████    ███████████████████████████'   .███
    +███    ███████████████████████████+   :███
    :███    ███████████████████████████'   +███
     ███    ███████████████████████████.   ███#
     ███.   #██████████████████████████    ███,
     ████    █████████████████████████+   `███
     '███    '████████████████████████    ████
      ███;    ███████████████████████     ███;
      ████     #████████████████████     ████ 
       ███#     .██████████████████     `███+ 
       ████`      ;██████████████       ████  
        ████         '███████#.        ████.  
        .████                         █████   
         '████                       █████    
          #████'                    █████     
           +█████`                ██████      
            ,██████:           `███████       
              ████████#;,..:+████████.        
               ,███████████████████+          
                 .███████████████;            
                    `+███████#,               

  • CohibAA
    Full Member
    ***
    Offline Offline

    Activity: 223
    Merit: 132



    View Profile WWW
    July 09, 2015, 11:10:49 PM
     #215
    Quote from: cakir on July 09, 2015, 11:04:40 PM
    Also how the hell is that possible?
    This tx broadcasted (spammed network) and  get accepted immediately; https://blockchain.info/tx/5f475e567548232d3b9f395b941c2ca8584df68492bd586937cd8d08f96c30e7
    It's outputs are lower than the min limit...

    Quote
    Relayed By    Slush

    They included it in the block...

  • sidhujag
    Legendary
    *
    Offline Offline

    Activity: 2044
    Merit: 1005


    View Profile
    July 09, 2015, 11:24:24 PM
     #216
    Quote from: cakir on July 09, 2015, 11:04:40 PM
    I bet first this guy (https://bitcointalk.org/index.php?action=profile;u=154254) (Yes, TKeenan) will come here and post something like that "Hey, let's use bigger blocks, don't you see we need it right now!"

    I'm still thinking Gavin is doing such spamming.

    Also how the hell is that possible?
    This tx broadcasted (spammed network) and  get accepted immediately; https://blockchain.info/tx/5f475e567548232d3b9f395b941c2ca8584df68492bd586937cd8d08f96c30e7
    It's outputs are lower than the min limit...

    Each block has a FIFO area in size where it accepts tx for free. do you mean DUST got accepted?

  • cryptosky
    Newbie
    *
    Offline Offline

    Activity: 20
    Merit: 0


    View Profile
    July 09, 2015, 11:35:23 PM
     #217
    Does anyone know who is making this stress test?

  • Alley
    Legendary
    *
    Offline Offline

    Activity: 910
    Merit: 1000


    View Profile
    July 10, 2015, 12:10:22 AM
     #218
    Back up to 72,000 unconfirmed tx.  I think this is the new normal.

  • canth
    Legendary
    *
    Offline Offline

    Activity: 1442
    Merit: 1001



    View Profile
    July 10, 2015, 12:17:45 AM
     #219
    Quote from: cryptosky on July 09, 2015, 11:35:23 PM
    Does anyone know who is making this stress test?

    Someone call the authorities and track down these transactions. Tongue  </endassclown comments>

    No, I don't think anyone knows the source of the spam/stress test this time around. Someone with a decent amount of funds and a motivation to force some improvements, I'd say.
    Reputation thread: https://bt.irlbtc.com/view/404667.0

  • JorgeStolfi
    Hero Member
    *****
    Offline Offline

    Activity: 910
    Merit: 1003



    View Profile
    July 10, 2015, 03:15:19 AM
     #220
    Quote from: sidhujag on July 09, 2015, 07:39:11 AM
    "If blocks are 8MB, the fees will fall, therefore the cost of getting 1MB of spam on the blockchain will fall.

    A Spam attack does not aim to put spam on the blockchain (there is plenty of it already), but to swamp the queues so as to deny service by hours or days.  With 1 MB blocks, the spammer needs to issue only 0.7 tx/s, at a sufficiently high fee, to keep legitimate transactions from being confirmed.  With 8 MB blocks, it would have to issue ~15 tx/s all at the same high fee to keep those same transactions from being confirmed.

    Hard to believe that the let-it-saturate-hooray camp can honestly think that SMALLER block sizes will make spam attacks more difficult.  What have they promised to their investors, that they need to resort to lies and ad-hominems to try to prevent any block increase?

    To prevent the filling up of the blockchain and the utxo tables with spam, there is a much simpler measure: set a fixed, hard, and significant transaction fee, say 0.2 mBTC (~0.05 USD), for each output, whatever its amount; and a fixed, hard, and significant minimum output value, say 0.1 mBTC (~0.03 USD).  Any existing UTXO smaller than this amount then can be removed from the tables.
    Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
    Pages: « 1 2 3 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 »
      Print  
Page 10
Viewing Page: 11

IRLBTC™ © 2025 IRLBTC.com