Bitcoin Forum
November 18, 2017, 07:01:30 AM *
News: Latest stable version of Bitcoin Core: 0.15.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 ... 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 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2008803 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 07:28:31 PM
 #28381

Cypherdoc, what are the latest updates regarding the block size debate ?

i'm not aware of any progress really.  you can follow bitcoin-dev mailing list for the details but everything i've seen there hasn't shown much progress.

may someone else who is really following it closely can comment.
1510988490
Hero Member
*
Offline Offline

Posts: 1510988490

View Profile Personal Message (Offline)

Ignore
1510988490
Reply with quote  #2

1510988490
Report to moderator
1510988490
Hero Member
*
Offline Offline

Posts: 1510988490

View Profile Personal Message (Offline)

Ignore
1510988490
Reply with quote  #2

1510988490
Report to moderator
1510988490
Hero Member
*
Offline Offline

Posts: 1510988490

View Profile Personal Message (Offline)

Ignore
1510988490
Reply with quote  #2

1510988490
Report to moderator
Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
pa
Hero Member
*****
Offline Offline

Activity: 516


View Profile
July 07, 2015, 07:38:59 PM
 #28382

Some of you will find this interesting: https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-228-sidechains-with-adam-back-and-andreas-antonoulos
stallion
Full Member
***
Offline Offline

Activity: 182


View Profile
July 07, 2015, 07:47:19 PM
 #28383

If we talk about fluctuation in the prices of gold , that has always happened in the economy . What hasn't happened is the people who are comfortable with Gold investing their bucks , into equity or Bitcoin , for that matter. Gold is the safe secure return ,and supports the traditional mindset. It needs to be changed.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 08:06:27 PM
 #28384

If we talk about fluctuation in the prices of gold , that has always happened in the economy . What hasn't happened is the people who are comfortable with Gold investing their bucks , into equity or Bitcoin , for that matter. Gold is the safe secure return ,and supports the traditional mindset. It needs to be changed.

until or unless Bitcoin can manage to get into the hands of ppl worldwide, esp that African kid mining for gold, it won't become a digital gold.
2112
Legendary
*
Offline Offline

Activity: 1960



View Profile
July 07, 2015, 08:08:37 PM
 #28385

:really off topic but I so rarely can add to the discussions. Tongue

Actually in order to address memory out of the address range of the cpu bus a "page swap" method was used which had been used on mainframes for many years, this was called expanded memory and was in 16k chunks which was very slow. with the 286 line extended memory was introduced and the cpu had to go into extended mode in order to access it. That of course if my memory serves me.
You should maybe serve your memory some fish, so that it could serve you better. Tongue

You've conflated several related concepts:

https://en.wikipedia.org/wiki/Extended_memory
https://en.wikipedia.org/wiki/Expanded_memory
https://en.wikipedia.org/wiki/Protected_mode
https://en.wikipedia.org/wiki/CDC_6600 and search for "ECS" (Extended Core Storage)

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Hueristic
Legendary
*
Offline Offline

Activity: 1442


Doomed to see the future and unable to prevent it


View Profile
July 07, 2015, 08:47:24 PM
 #28386

:really off topic but I so rarely can add to the discussions. Tongue

Actually in order to address memory out of the address range of the cpu bus a "page swap" method was used which had been used on mainframes for many years, this was called expanded memory and was in 16k chunks which was very slow. with the 286 line extended memory was introduced and the cpu had to go into extended mode in order to access it. That of course if my memory serves me.
You should maybe serve your memory some fish, so that it could serve you better. Tongue

You've conflated several related concepts:

https://en.wikipedia.org/wiki/Extended_memory
https://en.wikipedia.org/wiki/Expanded_memory
https://en.wikipedia.org/wiki/Protected_mode

:OFF Topic still
Yeah, those links verify what I said.

https://en.wikipedia.org/wiki/CDC_6600 and search for "ECS" (Extended Core Storage)

Was this the first page swapping mainframe?

BITSLER                 ▄███
               ▄████▀
             ▄████▀
           ▄████▀  ▄██▄
         ▄████▀    ▀████▄
       ▄████▀        ▀████▄
     ▄████▀            ▀████▄
   ▄████▀                ▀████▄
 ▄████▀ ▄████▄      ▄████▄ ▀████▄
█████   ██████      ██████   █████
 ▀████▄ ▀████▀      ▀████▀ ▄████▀
   ▀████▄                ▄████▀
     ▀████▄            ▄████▀
       ▀████▄        ▄████▀
         ▀████▄    ▄████▀
           ▀████▄▄████▀
             ▀██████▀
               ▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄            
▄▄▄▄▀▀▀▀    ▄▄█▄▄ ▀▀▄         
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄      
█  ▀▄▄  ▀█▀▀ ▄      ▀████   ▀▀▄   
█ █▄  ▀▄   ▀████       ▀▀ ▄██▄ ▀▀▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█  ▀▀       ▀▄▄ ▀████      ▄▄▄▀▀▀  █
█            ▄ ▀▄    ▄▄▄▀▀▀   ▄▄  █
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█ ▄▄   ███   ▀██  █           ▀▀  █ 
█ ███  ▀██       █        ▄▄      █ 
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  
▀▄            █        ▀▀      █  
▀▀▄   ███▄  █   ▄▄          █   
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀    
▀▀▄   █   ▀▀▄▄▄▀▀▀         
▄▄▄▄▄▄▄▄▄▄▄█▄▄▀▀▀▀              
              ▄▄▄██████▄▄▄
          ▄▄████████████████▄▄
        ▄██████▀▀▀▀▀▀▀▀▀▀██████▄
▄     ▄█████▀             ▀█████▄
██▄▄ █████▀                ▀█████
 ████████            ▄██      █████
  ████████▄         ███▀       ████▄
  █████████▀▀     ▄███▀        █████
   █▀▀▀          █████         █████
     ▄▄▄         ████          █████
   █████          ▀▀           ████▀
    █████                     █████
     █████▄                 ▄█████
      ▀█████▄             ▄█████▀
        ▀██████▄▄▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████████▀▀
              ▀▀▀██████▀▀▀
            ▄▄▄███████▄▄▄
         ▄█▀▀▀ ▄▄▄▄▄▄▄ ▀▀▀█▄
       █▀▀ ▄█████████████▄ ▀▀█
     █▀▀ ███████████████████ ▀▀█
    █▀ ███████████████████████ ▀█
   █▀ ███████████████▀▀ ███████ ▀█
 ▄█▀ ██████████████▀      ▀█████ ▀█▄
███ ███████████▀▀            ▀▀██ ███
███ ███████▀▀                     ███
███ ▀▀▀▀                          ███
▀██▄                             ▄██▀
  ▀█▄                            ▀▀
    █▄       █▄▄▄▄▄▄▄▄▄█
     █▄      ▀█████████▀
      ▀█▄      ▀▀▀▀▀▀▀
        ▀▀█▄▄  ▄▄▄
            ▀▀█████
[]
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
July 07, 2015, 09:02:08 PM
 #28387

Quote from: Luke-Jr
Eligius does not do any SPV mining. Empty blocks are generated only after the previous block has been fully verified, but before the next block's transaction set has been calculated.


It may come down to how you defined SPV mining I guess he is saying they try to mine on top of valid blocks and not empty ones.but if you get lucky you may have empty blocks in a row?

Would that be SPV mining?

Let's call it "empty block mining" instead.  He's right that it's not strictly SPV mining if you've indeed verified the previous block, but I think people are interested in the behaviour of Miners in the time between when a miner could begin hashing on an empty block, and when the hashers are actually working on a new non-empty block.  

So then there's:

   (1) empty block mining (previous block verified but new transaction set not built).
   (2) empty block mining (previous block not verified).  

EDIT: it would be nice to make a diagram to visualize all the steps that take place in the mining process.

Tier Nolan has provided a logical explanation of how SPV mining should be done, which of course is just part of the end-to-end process to cut over to a new working block.
https://bitcointalk.org/index.php?topic=1108668.msg11799081#msg11799081

gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2338



View Profile
July 07, 2015, 09:12:51 PM
 #28388

On the topic of block verification times, people on Reddit are saying this block (filled with one huge TX) took up to 25 seconds to verify:
yes, they're actually quoting pieter and I from #bitcoin-dev (telling the miner in advance that the transaction he was creating would take a _LONG_ time to verify). They created a huge non-standard 1MB transaction and part of the verification time is quadratic (in the number of inputs).

It's actually possible to create a block that would take many minutes to verify, though not with standard transactions-- only something contrived.

Bitcoin will not be compromised
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 09:52:26 PM
 #28389

On the topic of block verification times, people on Reddit are saying this block (filled with one huge TX) took up to 25 seconds to verify:
yes, they're actually quoting pieter and I from #bitcoin-dev (telling the miner in advance that the transaction he was creating would take a _LONG_ time to verify). They created a huge non-standard 1MB transaction and part of the verification time is quadratic (in the number of inputs).

It's actually possible to create a block that would take many minutes to verify, though not with standard transactions-- only something contrived.


and these have to be self mined, correct?
tvbcof
Legendary
*
Offline Offline

Activity: 2324


View Profile
July 07, 2015, 10:17:02 PM
 #28390

Clean and synched mempools makes for a cleaner blockchain, else garbage in - garbage out. Most mempools are synched because node owners don't usually mess with tx policy. They accept the defaults.
The blockchain itself constain substantial counter-eficidence. Any block over 750k is running with changed settings; as are a substantial chunk of the transactions.  I think this is all well and good, but it's not the case that its all consistent.

Quote
IBLT doesn't currently exist, and other mechenisms like the relay network protocol don't care about mempool synchronization levels.

IBLT does exist as it has been prototyped by Kalle and Rusty. It is just nowhere near ready for a pull request.
It has never relayed a _single_ block, not in a lab, not anywhere. It does _not_ exist. It certantly can and will exist-- though it's not yet clear how useful it will be over the relay network-- Gavin, for example, doesn't believe it will be useful "until blocks are hundreds of megabytes".

While you are bumming around here, Greg, perhaps you could comment on the first thing which hit me when I looked into IBLT.  Nobody else has.  The thought hit my partially because of who seemed to be promoting it.

1) w/ question

Solex posits the 'garbage in/garbage out' principle which IBLT is supposed to be able to address by helping everyone's mempool be syncronized.  It imediately struck me that some (if not most) people would consider blacklisted or non-whitelisted UTXOs as being 'garbage'.  It struck me that IBLT could be used as an efficient way for miners to be sure that they had 'properly' cleared their transaction list of 'garbage' transactions so they didn't 'waste their time' mining the 'wrong' transactions.  Has that danger/potential been explored by the techies?

2) w/o question

From my time as a mechanic and having a life-long interest in mechanical things, I will state that for optimizing efficiency and power, tight tolerances and precision are the way to go.  The trouble is that fairly small things that go wrong (say, a partial blockage of the radiator) can cause them to seize up.  When I raced motorcycles, the high performance ones were expected to be re-built after each race and the performance decline if one did not do this, or if any little thing went wrong was very noticeable and always fatal if one was performing near the top of the field (I was not.)

For rugged dependability one wants sloppy clearances, way over-designed parts, etc.  They don't run efficiently, but a lot of time that does not matter.  The most important thing is that the performance is predictable.

Trying valiantly to achieve high precision synchronization of every miner's mempools in nearly real-time across a network which is (hopefully) deliberately distributed seems like a bad idea.  Loose 'blocked' tolerances in transaction sequencing leaving construction completely up to individual miners just somehow 'feels' to me to be the way to go from a defensibly standpoint.  (Of course I don't give two shits about 0-conf transactions and consider them a negative, so it's easier for me to feel this way.)

But don't you think that I'm saying anything bad about it-- I'm not. Cypherdoc was arguing that mempools were (and had) to be the same, and cited IBLT as a reason---- but it cannot currently be a reason, because it doesn't exist.  Be careful about assigning virtue to the common fate aspect of it-- as it can make censorship much worse. (OTOH, rusty's latest optimizations reduce the need for consistency; and my network block coding idea-- which is what insired IBLT, but is more complex-- basically eliminates consistency pressure entirely)
...

Praise God!



cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 10:29:14 PM
 #28391

great Reddit thread about how the network of full nodes is VERY capable of handling much more than the FUD 2-3TPS being pushed.  it looks like it can handle anywhere from 221-442TPS at peak.  no wonder my full nodes have been sitting around unstressed and underutilized:

https://www.reddit.com/r/Bitcoin/comments/3cgyiv/new_transaction_record_442_txs_the_nodes_endured/
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 10:46:14 PM
 #28392

there's alot more going on than what meets the eye:

https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_transaction_ever_mined_999657_kb_consumes/csvbtp4

take it from an eye doctor.
Odalv
Legendary
*
Offline Offline

Activity: 1260



View Profile
July 07, 2015, 10:49:25 PM
 #28393

On the topic of block verification times, people on Reddit are saying this block (filled with one huge TX) took up to 25 seconds to verify:
yes, they're actually quoting pieter and I from #bitcoin-dev (telling the miner in advance that the transaction he was creating would take a _LONG_ time to verify). They created a huge non-standard 1MB transaction and part of the verification time is quadratic (in the number of inputs).

It's actually possible to create a block that would take many minutes to verify, though not with standard transactions-- only something contrived.


and these have to be self mined, correct?

I'm not sure everybody can broadcast transaction.
kano
Legendary
*
Offline Offline

Activity: 2268


Linux since 1997 RedHat 4


View Profile
July 07, 2015, 10:55:17 PM
 #28394

hey, since everybody and their mother now knows i'm an eye doc, how's your diabetic retinopathy?  i was dying to ask you that 3 yr ago back in my cgminer days when you first revealed that.  but that was before HF. Tongue   that's right up my alley you know.
Well, after lots of laser shots each visit (I'm pretty sure the total was 100 or more) I stopped going (about 2 years ago?)
Yeah I should get around to going back again when I can afford it Tongue (before I go blind)

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
tvbcof
Legendary
*
Offline Offline

Activity: 2324


View Profile
July 07, 2015, 11:07:37 PM
 #28395


hey, since everybody and their mother now knows i'm an eye doc, how's your diabetic retinopathy?  i was dying to ask you that 3 yr ago back in my cgminer days when you first revealed that.  but that was before HF. Tongue   that's right up my alley you know.

Well, after lots of laser shots each visit (I'm pretty sure the total was 100 or more) I stopped going (about 2 years ago?)
Yeah I should get around to going back again when I can afford it Tongue (before I go blind)

As best I can tell, about 50% of doctors are pure scammers and shills for the pharma (and related) medical/industrial complex.  Another 40% are clueless mainstreamers who simply regurgitate talking points from the pharma sponsored medical curriculum.  The other 10% are good scientists and honorable people who see through all the crap.

In the U.S., at least, I think that the whole field of medicine has moved to be mostly a system of wealth distribution and 'social justice.'  I swear to God I think that there are genuine efforts to make people sick as much as the other way around.

As far as I can see, someone who acts as their own attorney does indeed have fool for a client.  Not so with medicine.  In the few times when it has actually mattered I've gotten vastly better results by doing my own analysis and research.  There are a few exceptions but not all that many.


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 11:09:27 PM
 #28396

On the topic of block verification times, people on Reddit are saying this block (filled with one huge TX) took up to 25 seconds to verify:
yes, they're actually quoting pieter and I from #bitcoin-dev (telling the miner in advance that the transaction he was creating would take a _LONG_ time to verify). They created a huge non-standard 1MB transaction and part of the verification time is quadratic (in the number of inputs).

It's actually possible to create a block that would take many minutes to verify, though not with standard transactions-- only something contrived.


and these have to be self mined, correct?

I'm not sure everybody can broadcast transaction.

that's the pt.  someone over on Reddit is screaming that this 1MB single tx block is affirmation that bigger blocks is a BAD idea and they're extrapolating to a  20MB tx block as an example.  

2 points.  first f2pool wasn't performing an attack with this tx; it was actually helping the network by reducing the UTXO set by consolidating all those small inputs.  second, only a miner can execute a non-std tx of this size.  there is a 100kB max tx size in the IsStandard patch rules (credit nullc) that all propagated tx must adhere to to be a "std tx".  otherwise full nodes won't propagate them.  in other words, a typical gvt or bank spammer can't shove out into the network a huge 20MB non std tx except if it is a miner who self constructs this tx and self mines it.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 11:14:38 PM
 #28397

hey, since everybody and their mother now knows i'm an eye doc, how's your diabetic retinopathy?  i was dying to ask you that 3 yr ago back in my cgminer days when you first revealed that.  but that was before HF. Tongue   that's right up my alley you know.
Well, after lots of laser shots each visit (I'm pretty sure the total was 100 or more) I stopped going (about 2 years ago?)
Yeah I should get around to going back again when I can afford it Tongue (before I go blind)

clinically significant diabetic macular edema is not a good thing.  you need to tighten those blood sugar levels.  yes, laser and occasionally intravitreal injections of Avastin can be helpful.  good luck.
tvbcof
Legendary
*
Offline Offline

Activity: 2324


View Profile
July 07, 2015, 11:21:03 PM
 #28398

hey, since everybody and their mother now knows i'm an eye doc, how's your diabetic retinopathy?  i was dying to ask you that 3 yr ago back in my cgminer days when you first revealed that.  but that was before HF. Tongue   that's right up my alley you know.
Well, after lots of laser shots each visit (I'm pretty sure the total was 100 or more) I stopped going (about 2 years ago?)
Yeah I should get around to going back again when I can afford it Tongue (before I go blind)

clinically significant diabetic macular edema is not a good thing.  you need to tighten those blood sugar levels.  yes, laser and occasionally intravitreal injections of Avastin can be helpful.  good luck.

"Swear to God;  Hope to Die;  Stick a needle in my eye."


lunarboy
Hero Member
*****
Offline Offline

Activity: 544



View Profile
July 07, 2015, 11:26:27 PM
 #28399

great Reddit thread about how the network of full nodes is VERY capable of handling much more than the FUD 2-3TPS being pushed.  it looks like it can handle anywhere from 221-442TPS at peak.  no wonder my full nodes have been sitting around unstressed and underutilized:

https://www.reddit.com/r/Bitcoin/comments/3cgyiv/new_transaction_record_442_txs_the_nodes_endured/

Yeah these three buried posts cleared a few things up

Quote
Tardigrade1 8 points 2 hours ago*

Well, not entirely true. There is more to processing a transaction than propagating and storing it. But now that discussion has proven wrong and confirming that the only problem is the blocksize. There is no reason not to upgrade from a node/network perspective.

Before these spam attacks there was definitly discussion about if the nodes could handle the large volume of tx/s spamming them. This has now gone.

 

[–]awemany 11 points an hour ago*

This is a very good point. What you are basically saying is this, if I understand you correctly - please correct me if I am wrong:

The Bitcoin network got indeed 442tx/s for a short while, filling up mempools.

That means that nodes processed and validated 442tx/s for a while. They only didn't write them to the block chain, to disk as valid blocks, because enforced protocol rules right now prevent that.

The only reason the average actual rate didn't go up to 442tx/s is because the hard blocksize limit prevents blocks from being that large.

Note that without IBLT being implemented yet, you'd have to cut the effective transaction rate in half. Mined blocks would about contain the same number of transactions that get put into the network.

But this still means that the current, as-is Bitcoin network can handle 221 tx/s for a short period of time.

I think it is thus very safe to assume it can handle at least a tenth of that (to play it extra safe) continuously.

That would be 22.1tx/s. ~7MB blocks.

Lets please remove the damn limit now.

[–]Tardigrade1 12 points an hour ago

Yes precisely. This spam-attack has been far more interesting than people here realize. What we learnt was that a very high rate of transactions can still successfully propagate across the world, from node to node. Then they just wait to be included in the block.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 08, 2015, 01:02:41 AM
 #28400

great Reddit thread about how the network of full nodes is VERY capable of handling much more than the FUD 2-3TPS being pushed.  it looks like it can handle anywhere from 221-442TPS at peak.  no wonder my full nodes have been sitting around unstressed and underutilized:

https://www.reddit.com/r/Bitcoin/comments/3cgyiv/new_transaction_record_442_txs_the_nodes_endured/

Yeah these three buried posts cleared a few things up

Quote
Tardigrade1 8 points 2 hours ago*

Well, not entirely true. There is more to processing a transaction than propagating and storing it. But now that discussion has proven wrong and confirming that the only problem is the blocksize. There is no reason not to upgrade from a node/network perspective.

Before these spam attacks there was definitly discussion about if the nodes could handle the large volume of tx/s spamming them. This has now gone.

 

[–]awemany 11 points an hour ago*

This is a very good point. What you are basically saying is this, if I understand you correctly - please correct me if I am wrong:

The Bitcoin network got indeed 442tx/s for a short while, filling up mempools.

That means that nodes processed and validated 442tx/s for a while. They only didn't write them to the block chain, to disk as valid blocks, because enforced protocol rules right now prevent that.

The only reason the average actual rate didn't go up to 442tx/s is because the hard blocksize limit prevents blocks from being that large.

Note that without IBLT being implemented yet, you'd have to cut the effective transaction rate in half. Mined blocks would about contain the same number of transactions that get put into the network.

But this still means that the current, as-is Bitcoin network can handle 221 tx/s for a short period of time.

I think it is thus very safe to assume it can handle at least a tenth of that (to play it extra safe) continuously.

That would be 22.1tx/s. ~7MB blocks.

Lets please remove the damn limit now.

[–]Tardigrade1 12 points an hour ago

Yes precisely. This spam-attack has been far more interesting than people here realize. What we learnt was that a very high rate of transactions can still successfully propagate across the world, from node to node. Then they just wait to be included in the block.


M_O_A is making an ass of himself throughout that thread.
Pages: « 1 ... 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 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 ... 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!