Bitcoin Forum
December 11, 2017, 07:25:55 PM *
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 ... 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 [1419] 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2022036 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 03:55:21 PM
 #28361

back with a vengeance:

FORTUNEJACK.COM[
                            
9 BTC WELCOME PACK FOR 1ST 5 DEPOSITS
FREE 1,000 mBTC daily for LuckyJack winners
[
          
]
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513020355
Hero Member
*
Offline Offline

Posts: 1513020355

View Profile Personal Message (Offline)

Ignore
1513020355
Reply with quote  #2

1513020355
Report to moderator
1513020355
Hero Member
*
Offline Offline

Posts: 1513020355

View Profile Personal Message (Offline)

Ignore
1513020355
Reply with quote  #2

1513020355
Report to moderator
1513020355
Hero Member
*
Offline Offline

Posts: 1513020355

View Profile Personal Message (Offline)

Ignore
1513020355
Reply with quote  #2

1513020355
Report to moderator
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
July 07, 2015, 03:58:41 PM
 #28362

Coz someone linked a post earlier in this thread ...

For pools that normally mine full blocks as well as uncommon empty blocks, the empty blocks are the work the pool sends every block change.
They are of the opinion that because Luke-jr's eloipool is shit slow at handling block changes, they should send out empty work first and then full work soon after it.
Obviously the empty work is mined for a small % of the average block change length so it would also mean that the miners finding block with the empty work would be a smaller % of all the blocks found by the pools that do this.

As I've explained in the empty blocks thread, when comparing eligius with it's empty block change work and my pool https://kano.is/ with our full block change work, my pool beats eligius on average sending out block change work.
During normal times when the relay is working and there isn't a massive spam test running, my pools beats eloipool >90% of the time with block changes.

hey, the great kano.  thx for the explanation.

why haven't i seen Eligius mining 0 tx blocks, or have i just missed it?  so this SPV mining is not confined to China?  i thought this was primarily an inferior connectivity issue behind the GFC?  why haven't we seen it before with Eligius if this is his norm?

I was chatting with Luke-jr last night on Reddit, Eligius mines lots of 0tx blocks he said they don't SPV mine so it's just Kano is saying, they are just slow to transition.

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.


Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 03:59:08 PM
 #28363

there's a real battle going on at Bitstamp.  aren't they close to Greece?  i wouldn't be too pessimistic.

tvbcof
Legendary
*
Online Online

Activity: 2338


View Profile
July 07, 2015, 03:59:40 PM
 #28364

ok, i'm not getting the bolded part.  this graph shows 37 MB worth of unconf tx's, no?:
No clue, no node I have access to is seeing that much-- they may have turned off the minfee rules (not unreasonable for a metrics thing)...

Even given that, again, 37MB doesn't explain your swap.

yeah, i had noticed that.  strange...

Maybe a bloated swap file is a surprise Easter egg 'feature' of XT nodes?

As I said weeks ago, good luck getting BTC core devs to help fix it when your Gavinsista troll fork goes haywire.   Tongue

LOL (as usual.)  I wonder if anyone has even build XT for themselves rather than simply running someone else's build.

Cypherdoc noticed significant swap usage but went on to state that his machine was woefully 'underutilized' anyway.  Typical.

It's bizarre to me that RAM use is so low while swap is significant, but I'm not familiar with whatever tool it is that produces the GUI he screencap'd.  I wonder if he'd just triggered some sort of preen operation or killed an auxiliary analysis process or something to try to produce numbers which he could pass off to the (even more) ignorant that his machine was running fine.


Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
July 07, 2015, 04:01:39 PM
 #28365

I had to go back 500 days to get enough data for Eligius, but it looks like they have historically produced more empty blocks when the previous block was large, similar to F2Pool. 


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

Activity: 1064



View Profile
July 07, 2015, 04:12:22 PM
 #28366

I was chatting with Luke-jr last night on Reddit, Eligius mines lots of 0tx blocks he said they don't SPV mine so it's just Kano is saying, they are just slow to transition.

Why would a pool ever mine an empty block if they weren't SPV mining (at least for a short amount of time while they validate the previous block and before they re-assign the hashers a new non-empty block to work on)?

Personally, I find it difficult to communicate with Luke-Jr because he will often argue based on a technicality due to his own personal definitions of some word, rather than talking about the thing everyone is actually trying to talk about.  It looks like he does this in other sub-reddits too, for example, he claims that the Pope is not the Pope.

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

Activity: 1764



View Profile
July 07, 2015, 04:14:50 PM
 #28367

I was chatting with Luke-jr last night on Reddit, Eligius mines lots of 0tx blocks he said they don't SPV mine so it's just Kano is saying, they are just slow to transition.

Why would a pool ever mine an empty block if they weren't SPV mining (at least for a short amount of time while they validate the previous block and before they re-assign the hashers a new non-empty block to work on)?

Personally, I find it difficult to communicate with Luke-Jr because he will often argue based on a technicality due to his own personal definitions of some word, rather than talking about the thing everyone is actually trying to talk about.  It looks like he does this in other sub-reddits too, for example, he claims that the Pope is not the Pope.

a couple others do exactly that too.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 04:20:11 PM
 #28368

oh Lordy.  trusty SLW off the cliff!:

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 04:22:56 PM
 #28369

if you're a goldbug, you have GOT to be concerned:

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 04:27:57 PM
 #28370

growth?  what fricking growth?

copper:


Freeport:


BHP:


oil:



Chevron:
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 04:31:00 PM
 #28371

hmm, i wonder if those 2 SPV blocks could cause a fork?

Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
July 07, 2015, 04:35:18 PM
 #28372

I was chatting with Luke-jr last night on Reddit, Eligius mines lots of 0tx blocks he said they don't SPV mine so it's just Kano is saying, they are just slow to transition.

Why would a pool ever mine an empty block if they weren't SPV mining (at least for a short amount of time while they validate the previous block and before they re-assign the hashers a new non-empty block to work on)?

Personally, I find it difficult to communicate with Luke-Jr because he will often argue based on a technicality due to his own personal definitions of some word, rather than talking about the thing everyone is actually trying to talk about.  It looks like he does this in other sub-reddits too, for example, he claims that the Pope is not the Pope.

Here is his answer to: I've notice eligius mining multiple empty blocks in a row, is that because they are SPV mining too, and if you know and it's open, what is the SPV mining policy?


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?

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 04:42:07 PM
 #28373

I was chatting with Luke-jr last night on Reddit, Eligius mines lots of 0tx blocks he said they don't SPV mine so it's just Kano is saying, they are just slow to transition.

Why would a pool ever mine an empty block if they weren't SPV mining (at least for a short amount of time while they validate the previous block and before they re-assign the hashers a new non-empty block to work on)?

Personally, I find it difficult to communicate with Luke-Jr because he will often argue based on a technicality due to his own personal definitions of some word, rather than talking about the thing everyone is actually trying to talk about.  It looks like he does this in other sub-reddits too, for example, he claims that the Pope is not the Pope.

Here is his answer to: I've notice eligius mining multiple empty blocks in a row, is that because they are SPV mining too, and if you know and it's open, what is the SPV mining policy?


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?

yes, the defiinition is important.  all these guys are trying to shave milliseconds of the time to start hashing the next block after arrival of a block. 

before Luke, we had been talking about starting hashing of a 0tx blk immediately upon receipt of a "large" block, however that's defined by the pool to attempt to save the time of validating that large blk.  once validated, they sub out the 0tx with a blk with tx's and resume hashing.

Luke apparently gets a blk, large or small, validates it, then routinely sends out a 0tx blk to start hashing, just b/c he wants to save the milliseconds it takes to construct the tx template for a blk with tx's.  once constructed, he resends that blk out with the tx's.
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
July 07, 2015, 04:53:55 PM
 #28374

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.

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

Activity: 1036


View Profile
July 07, 2015, 06:17:14 PM
 #28375

From the devs' perspective, they have to deal with a lot of non-technical people, so dismissing arguments based on a technicality becomes a go-to tactic. They might justify it based on the fact that the person is clearly completely off-base and has nothing useful to say. This tactic is easier than explaining why.

The problem comes when they use that to justify dismissing someone even when they can't really be sure if they're completely off-base. It becomes a kind of last-ditch "panic button" for when they want to avoid addressing something.
domob
Legendary
*
Offline Offline

Activity: 983


View Profile WWW
July 07, 2015, 06:46:05 PM
 #28376

there's a real battle going on at Bitstamp.  aren't they close to Greece?  i wouldn't be too pessimistic.

They are in Slovenia.  Not really too close to Greece from a European point of view.  I never heard talk about Slovenia (which is part of the Eurozone), so it probably is at least better off than Italy and Spain.

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
Hueristic
Legendary
*
Offline Offline

Activity: 1470


Doomed to see the future and unable to prevent it


View Profile
July 07, 2015, 06:53:44 PM
 #28377

Whether 1MB is ideal or not, it's what we have.

As it happens, 1MB seemed to have been at least quite fortuitous for us, and I wonder if it were not somewhat well considered when Satoshi made the setting as opposed to the perception promulgated by some that he pulled a random number out his ass.

In retrospect, 1MB seems like a pretty ideal setting for the past history of Bitcoin and some distance into the future.  To me.

Exactly this.  Intentionally or not, 1MB turned out to be a serendipitous choice.  Now it has ossified and is ready for the next layers to be built on its solid foundation.

I favor Adam Backamoto's extension block proposal.

The 1MB blocksize limit reminds me of the old 640k limit in DOS.

Rather than destroy Window's interoperability with the rich/valuable legacy of 8088 based software, that limit was extended via various hacks sublime software engineering.

Before resorting to the nuclear option of a contentious hard fork, we should attempt to achieve the desired result with soft forks.

: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.

BITSLER                 ▄███
               ▄████▀
             ▄████▀
           ▄████▀  ▄██▄
         ▄████▀    ▀████▄
       ▄████▀        ▀████▄
     ▄████▀            ▀████▄
   ▄████▀                ▀████▄
 ▄████▀ ▄████▄      ▄████▄ ▀████▄
█████   ██████      ██████   █████
 ▀████▄ ▀████▀      ▀████▀ ▄████▀
   ▀████▄                ▄████▀
     ▀████▄            ▄████▀
       ▀████▄        ▄████▀
         ▀████▄    ▄████▀
           ▀████▄▄████▀
             ▀██████▀
               ▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄            
▄▄▄▄▀▀▀▀    ▄▄█▄▄ ▀▀▄         
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄      
█  ▀▄▄  ▀█▀▀ ▄      ▀████   ▀▀▄   
█ █▄  ▀▄   ▀████       ▀▀ ▄██▄ ▀▀▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█  ▀▀       ▀▄▄ ▀████      ▄▄▄▀▀▀  █
█            ▄ ▀▄    ▄▄▄▀▀▀   ▄▄  █
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█ ▄▄   ███   ▀██  █           ▀▀  █ 
█ ███  ▀██       █        ▄▄      █ 
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  
▀▄            █        ▀▀      █  
▀▀▄   ███▄  █   ▄▄          █   
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀    
▀▀▄   █   ▀▀▄▄▄▀▀▀         
▄▄▄▄▄▄▄▄▄▄▄█▄▄▀▀▀▀              
              ▄▄▄██████▄▄▄
          ▄▄████████████████▄▄
        ▄██████▀▀▀▀▀▀▀▀▀▀██████▄
▄     ▄█████▀             ▀█████▄
██▄▄ █████▀                ▀█████
 ████████            ▄██      █████
  ████████▄         ███▀       ████▄
  █████████▀▀     ▄███▀        █████
   █▀▀▀          █████         █████
     ▄▄▄         ████          █████
   █████          ▀▀           ████▀
    █████                     █████
     █████▄                 ▄█████
      ▀█████▄             ▄█████▀
        ▀██████▄▄▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████████▀▀
              ▀▀▀██████▀▀▀
            ▄▄▄███████▄▄▄
         ▄█▀▀▀ ▄▄▄▄▄▄▄ ▀▀▀█▄
       █▀▀ ▄█████████████▄ ▀▀█
     █▀▀ ███████████████████ ▀▀█
    █▀ ███████████████████████ ▀█
   █▀ ███████████████▀▀ ███████ ▀█
 ▄█▀ ██████████████▀      ▀█████ ▀█▄
███ ███████████▀▀            ▀▀██ ███
███ ███████▀▀                     ███
███ ▀▀▀▀                          ███
▀██▄                             ▄██▀
  ▀█▄                            ▀▀
    █▄       █▄▄▄▄▄▄▄▄▄█
     █▄      ▀█████████▀
      ▀█▄      ▀▀▀▀▀▀▀
        ▀▀█▄▄  ▄▄▄
            ▀▀█████
[]
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
July 07, 2015, 07:09:38 PM
 #28378

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:

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

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

Activity: 1022


Permabull Bitcoin Investor


View Profile
July 07, 2015, 07:17:30 PM
 #28379

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

Quote from:  Satoshi Nakamoto
Feb. 14, 2010: I’m sure that in 20 years there will either be very large transaction volume or no volume.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 07:20:35 PM
 #28380

as you know, even Gavin talks about this memory problem from UTXO.  and yes, i read the Reddit thread that resulted in which you participated and i'm aware that UTXO can be dynamically cached according to needs.
http://gavinandresen.ninja/utxo-uhoh

Gavin was insufficently precise. There is a reddit thread is full of people calling gavin a fool ( Sad ) for saying "memory" when he should have been saying fast storage.  https://twitter.com/petertoddbtc/status/596710423094788097

Why do you think it's prudent to argue this with me?

Okay, lets take a bet. Since you're so confident; surely you'll grant me 1000:1 odds?-- I'll give my side away to a public cause.

The question is "Is the entire UTXO set kept in ram in Bitcoin Core ever released?"

I will bet 3 BTC and, with the 1000:1 odds, if you lose you'll pay 3000 BTC (which I will to the hashfast liquidators, to return it to the forum members that it was taken from; which will also save you some money in ongoing lawsuit against you).

Sounds good?  How will we adjudicate?  If not, what is your counter-offer for the terms?

Quote
i didn't say this full block spam attack we're undergoing wasn't affecting my node at_all.  sure, i'm in swap, b/c of the huge #unconf tx's but it hasn't shut down or stressed my nodes to any degree.  one of the arguments by Cripplecoiners was that these large block attacks would shut full nodes down from destabilization resulting in centralization.  i'm not seeing that.
The highest number of unconfirmed transactions I've seen ever is about 8MB. Even if we assume the real max was 3x that this is not explaining your hundreds of megabytes of swap.   We just had half the hashpower of the network mining without validating creating multiple large forks and large reorginizations, but you don't see any destabilization. Okay.

Let me chime in hear quickly, because I think Greg and I are talking about slightly different things.  My model was considering the time between the first moment that a pool could begin hashing on a blockheader, and when the previous block had been processed, a new non-empty block template constructed, and the hashers re-assigned to work on this non-empty block.  

It looks like this time, empirically, is 15 sec (F2Pool) and 30 sec (AntPool), based on these estimates.  

Here I suspect you're suffering from an excess of empiracisism without adequately devling into the mechenism.   You can directly measure that time time from input to minable on an actual node under your control and will observe the time is hundreds of times faster than your estimate. Why?   Miners don't magically know when their pool has new work, they'll get work in the first milliseconds and then grind on it some time before submitting returning work.  Even if the pool long polls them, it takes time to replace work. So what I suspect you're actually measuring there is the latency of the mining process...  which is consistent with what we've expirenced with P2Pool (5-20 second latencies from ASIC miners are common).

I noted you posted a result of a classification, did you run the same data through a simple logistic regression with prior size as the treatment? The intercept in the model would be interesting.

But indeed, these conversations have been conflating several seperate issues (latency vs throughput, etc.). Tricky to avoid that since they're all relevant.

but you haven't verified that f2pool or Antpool has increased their minrelaytxfee have you to minimize their mempool?
I have, they'd previously cranked it down, and were producing small blocks and were flamed in public.  They've since turned it back up.

Quote
remember, this whole mempool discussion was based off you responding to Peter's mathematics post the other day where you argued that the block verification times were only 80ms for a 250 kB block b/c tx's had been pre-verified after being passed around to all nodes across the network and didn't require re-verification by miners on the relay network and was therefore a refutation of his hypothesis of increasing block verification times (16-37sec on avg) leading to SPV mining.
As PeterR points out, they only need to wait for verification to actually verify (which they're not doing today), though they may have to wait longer to include transactions---- though I point out thats not fundimental e.g. no matter how big the backlog is you can produce a template sufficient to completely fill a block while doing no more work than handling a mempool of twice the maximum block size.  (by using a tiered mempool, though no one has bothered to implement this yet-- no one has even been complaining about how long createnewblock takes, due to the ability to produce empty blocks without skipping transactions).


well, you did claim some of it was in RAM; https://www.reddit.com/r/Bitcoin/comments/35asg6/gavin_andresen_utxo_uhoh/cr2za45
Pages: « 1 ... 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 [1419] 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 ... 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!