Bitcoin Forum
November 09, 2024, 07:42:45 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
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 ... 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 [1408] 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 ... 1557 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2032243 times)
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
July 05, 2015, 07:59:28 AM
Last edit: July 05, 2015, 08:55:34 AM by smooth
 #28141

My point about my personal preference where I employed the word "clusterfuck" to describe the hundreds of Cryptonote clones and that Monero's marketing (on these forums) to some extent had to vilify other CN clones in order to assert its dominance of CN clones

I can see why one might want to spin it that way. In fact Monero's dominance was largely assured by the fact that it was the first (even remotely) fairly launched cryptonote coin. The 82% ninja premine fraud was never going to fly. None of the others were sufficiently better in terms of features, leadership, community or anything else, to overcome that lead.

Quote
is instead I would have preferred to add features to CN that would naturally assert dominance over other CN clones.

Again, the dominance was never really in question, but it also isn't clear that "features" are needed (or at least  they don't need to be rushed out in some sort of race) or that a feature war is that way to go. A large part of the user base simply wants a non-transparent blockchain with a credibly reviewed, sufficiently refined, and well maintained (and therefore for these three reasons relatively secure and stable) code base.

Quote
It would behove Monero to be the first CN coin to apply my suggested fix to insure combinatorial analysis of partially overlapping rings can't occur

There is an ongoing question (requiring actually analysis and research, not just forum posts) whether this change to the privacy model is needed or desired. It is being considered.
tvbcof
Legendary
*
Offline Offline

Activity: 4746
Merit: 1282


View Profile
July 05, 2015, 08:13:11 AM
 #28142

We just need someone to figure out how to constantly feed them invalid blocks. Wink

I'm surprised to hear this from you, Holliday.  Can you explain why you think mining on the blockheader during the short time it takes to validate the block is bad?  It is clearly the profit-maximizing strategy, and I also believe it is ethically sound (unlike replace-by-fee).  

I personally don't see much wrong with replace-by-fee, but I'm old-school and believe that everyone who uses native Bitcoin should do so based on confirmations and tuning the number of confirmations one needs based on the value and importance of a given transaction, operational aspects of the functioning system at a given time, etc. This was, to me, always a fundamental concept of Bitcoin.  Trying to mold Bitcoin into a real-time system has resulted in the problems and hassles which simply do not need to exist, and that is even more the case when sidechains can proxy Bitcoin via a more purpose-oriented instant transaction solutions.

RBF has been described as 'vandalism'.  I don't see it that way as much as a timely and necessary lesson delivered in a way that will make more people perk up their ears and listen before it is to late (if it is not already.)  Irrespective of Satoshi's writings I consider SPV to be fraught with risks and dangers.

The only possible upside here is that perhaps these dick-head miners will pay the ultimate price and that we'll be more-or-less forced to entirely re-do (and more closely tie) the mining and transfer functions of the network.  In doing so, throwing sha256 out on it's ass as an side-effect would be quite positive to my way of thinking.


sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
July 05, 2015, 08:15:17 AM
Last edit: July 05, 2015, 09:37:05 AM by Peter R
 #28143

We just need someone to figure out how to constantly feed them invalid blocks. Wink

I'm surprised to hear this from you, Holliday.  Can you explain why you think mining on the blockheader during the short time it takes to validate the block is bad?  It is clearly the profit-maximizing strategy, and I also believe it is ethically sound (unlike replace-by-fee).  

Are they mining on the blockheader during the short time it takes to validate the block, or are they simply skipping validation entirely?

Miners are supposed to secure the network, ehh? If they are just blindly mining on whatever they are fed, they aren't doing a very good job, are they?

Clearly F2Pool messed up.  And they lost 100 BTC because of it.  But that wasn't for SPV mininig during the short amount of time it takes to process the previous block; it was for not bothering to validate the previous block at all.

SPV mining while the previous block is being verified is the profitable strategy, as shown here.  It also serves to produce "defensive blocks" that limit the effective blocksize without the need for a protocol-enforced blocksize limit, as discussed here.

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

Activity: 1162
Merit: 1007



View Profile
July 05, 2015, 08:25:45 AM
 #28144

Clearly F2Pool messed up.  And they lost 100 BTC because of it.  But that wasn't for SPV mininig during the short amount of time it takes to process the previous block; it was from not bothering to validate the previous block at all.

Right, and that's the harmful behavior which led to my response above.

SPV mining while the previous block is being verified is the profitable strategy, as shown here.  It also serves to produce "defensive blocks" that limit the effect blocksize without the need for a protocol-enforced blocksize limit, as discussed here.

I see no problem with SPV mining while verifying the previous block. It would also make my above suggestion pointless.

Cool.  Seems we agree then.

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

Activity: 1162
Merit: 1007



View Profile
July 05, 2015, 08:27:37 AM
 #28145

We just need someone to figure out how to constantly feed them invalid blocks. Wink

I'm surprised to hear this from you, Holliday.  Can you explain why you think mining on the blockheader during the short time it takes to validate the block is bad?  It is clearly the profit-maximizing strategy, and I also believe it is ethically sound (unlike replace-by-fee).  

I personally don't see much wrong with replace-by-fee...

I'd like to hear Holliday's take on replace-by-fee. And DeathAndTaxes take on this too (where did he go??).

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Mixles
Member
**
Offline Offline

Activity: 63
Merit: 11


View Profile
July 05, 2015, 08:52:01 AM
 #28146

I see no problem with SPV mining while verifying the previous block. It would also make my above suggestion pointless.

Yes.

Moreover, I don't see why the time spent verifying would be significant. The vast majority of transactions would have been verified by a full node before being included in the block, and then it is just a case of checking the hash, and looking up that the txn was previously mempool verified. The verification time for a block should be insignificant relative to its download time (unless it's a flood attack of new txns by a miner). Or am I missing something?

Donations to 1SumKArxoEJ1HoGibmj8ygw1DZWYBvjmM
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
July 05, 2015, 08:54:23 AM
 #28147

I see no problem with SPV mining while verifying the previous block. It would also make my above suggestion pointless.

Yes.

Moreover, I don't see why the time spent verifying is very significant. The vast majority of transactions would have been verified by a full node before being included in the block, and then it is just a case of checking the hash. The verification time for a block would then be insignificant relative to its download time.

Great point.  Does anyone know how Bitcoin Core currently works in this regards?  Is every transaction in a block (re-) verified?  Or are the transactions first hashed, and if matched to a TX in mempool not re-verified, thus saving time. 

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Mixles
Member
**
Offline Offline

Activity: 63
Merit: 11


View Profile
July 05, 2015, 08:56:16 AM
Last edit: July 05, 2015, 09:06:44 AM by Mixles
 #28148

Great point.  Does anyone know how Bitcoin Core currently works in this regards?  Is every transaction in a block (re-) verified?  Or are the transactions first hashed, and if matched to a TX in mempool not re-verified, thus saving time.  

It would be stupid to forward unverified txns, and it would also be stupid to verify them twice. Easy to fix, so there's no reason for it to verify twice.

About 600 milliseconds to verify a 1MB block, will be reduced to about 10 ms

https://github.com/bitcoin/bitcoin/pull/6077

https://github.com/bitcoin/bitcoin/pull/5835

Donations to 1SumKArxoEJ1HoGibmj8ygw1DZWYBvjmM
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
July 05, 2015, 09:03:07 AM
 #28149

Great point.  Does anyone know how Bitcoin Core currently works in this regards?  Is every transaction in a block (re-) verified?  Or are the transactions first hashed, and if matched to a TX in mempool not re-verified, thus saving time.  

It would be stupid to forward unverified txns, and it would also be stupid to verify them twice. Easy to fix, so there's no reason for it to verify twice.

https://github.com/bitcoin/bitcoin/pull/5835

Thanks.  So it looks like the fix was implemented this February, and that now TXs are not re-verified if they're already in mempool?

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Mixles
Member
**
Offline Offline

Activity: 63
Merit: 11


View Profile
July 05, 2015, 09:04:46 AM
 #28150

Great point.  Does anyone know how Bitcoin Core currently works in this regards?  Is every transaction in a block (re-) verified?  Or are the transactions first hashed, and if matched to a TX in mempool not re-verified, thus saving time.  

It would be stupid to forward unverified txns, and it would also be stupid to verify them twice. Easy to fix, so there's no reason for it to verify twice.

https://github.com/bitcoin/bitcoin/pull/5835

Thanks.  So it looks like the fix was implemented this February, and that now TXs are not re-verified if they're already in mempool?

Not sure if any solution is merged yet (see my edit above). But we are talking less than 600ms even without the extra speedup, or 10ms with the speedup.

Donations to 1SumKArxoEJ1HoGibmj8ygw1DZWYBvjmM
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
July 05, 2015, 09:07:50 AM
 #28151

...we are talking less than 100ms even without the fix.

Thanks Mixles!  Do you have any thoughts on why F2Pool and AntPool are mining so many empty blocks if the previous block can be validated so quickly?

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Mixles
Member
**
Offline Offline

Activity: 63
Merit: 11


View Profile
July 05, 2015, 09:17:20 AM
 #28152

Thanks Mixles!  Do you have any thoughts on why F2Pool and AntPool are mining so many empty blocks if the previous block can be validated so quickly?

They gain a 600ms advantage on the verification, then another few seconds on the download, depending on their bandwidth. 600 seconds average in a block, so if they manage to get an advantage of 10 seconds, that's 10/600 or 2% greater profitability than other miners. There will be less incentive for that when the reward halvings happen (fees double relative to subsidy). *shrug* Maybe they are also making some political point, or simply can't be bothered dealing with the txns. But the recent orphans should have cost them a bit. They are playing their own sort of game theories, and not always winning.

Donations to 1SumKArxoEJ1HoGibmj8ygw1DZWYBvjmM
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
July 05, 2015, 09:34:07 AM
 #28153

Thanks Mixles!  Do you have any thoughts on why F2Pool and AntPool are mining so many empty blocks if the previous block can be validated so quickly?

They gain a 600ms advantage on the verification, then another few seconds on the download, depending on their bandwidth. 600 seconds average in a block, so if they manage to get an advantage of 10 seconds, that's 10/600 or 2% greater profitability than other miners. There will be less incentive for that when the reward halvings happen (fees double relative to subsidy). *shrug* Maybe they are also making some political point, or simply can't be bothered dealing with the txns. But the recent orphans should have cost them a bit. They are playing their own sort of game theories, and not always winning.

I'm not sure I'm following.  Based on the ratio of empty blocks to non-empty blocks, it looks like the mean time to process a block is 16 sec and 35 sec for F2Pool and AntPool, respectively.  Are you suggesting they're "faking it"?


Run Bitcoin Unlimited (www.bitcoinunlimited.info)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
July 05, 2015, 09:42:12 AM
Last edit: July 05, 2015, 09:56:32 AM by TPTB_need_war
 #28154

My point about my personal preference where I employed the word "clusterfuck" to describe the hundreds of Cryptonote clones and that Monero's marketing (on these forums) to some extent had to vilify other CN clones in order to assert its dominance of CN clones

I can see why one might want to spin it that way. In fact Monero's dominance was largely assured by the fact that it was the first (even remotely) fairly launched cryptonote coin. The 82% ninja premine fraud was never going to fly. None of the others were sufficiently better in terms of features, leadership, community or anything else, to overcome that lead.

That is another potentially valid perspective. I guess I was just a bit turned off at the community's treatment of BoolBerry (even allegations that he was one of the original Bytecoin devs and that should imply distrust). It wasn't like you guys created CN and he was copying your whitepaper. I do however balance that with someone in his community trying to talk up BoolBerry's features as somehow radically superior to Monero's.

Again I think the heart of it for me personally is that felt Monero doesn't really own anything, other than its own (perhaps smaller than Bitcoin's rather small) community and its refined implementation. In the sense that Python owns its syntax. If you create a JPython you are still helping Python. If you create a BitcoinJ, you are still helping Bitcoin. This is what I meant when I wrote the ecosystem was a "clusterfuck" (or let's say non-ideal). We had developers and communities fighting each other on the same protocol. It felt like copycoins vs. Bitcoin, except in this case none of them were the first and legitimate one.

One of the signs of leadership is being able to get everyone working together.

I would have wanted to differentiate from CN and Bytecoin rather than claim ownership of the mess. Any way, I have the benefit of non-involvement and hindsight (heckling from the bleachers, not in the game, can't be tackled). I do understand you all are trying to bring an important technology to the market and make it stable.

Someone remarked why I didn't join a CN coin's effort. So I just wanted to make my personal reasons clear. It doesn't mean there is a problem with Monero now. It was just my reasons last year. And now it is too late for me to change my decision. Also I was more ill at that time, was still learning, and at the time I didn't think ring-sigs were the "end all and be all". Then by the time I started to think on chain anonymity is the holy grail (due to autonomy and end-to-end principle), I had pretty much backed off any efforts in this space late 2014. Recently epiphanies changed my outlook and my health also perhaps improved somewhat.

Mixles
Member
**
Offline Offline

Activity: 63
Merit: 11


View Profile
July 05, 2015, 09:57:53 AM
Last edit: July 05, 2015, 10:16:29 AM by Mixles
 #28155

I'm not sure I'm following.  Based on the ratio of empty blocks to non-empty blocks, it looks like the mean time to process a block is 16 sec and 35 sec for F2Pool and AntPool, respectively.  Are you suggesting they're "faking it"?

You're assuming they are perfectly rational, and have remained perfectly rational during the measurement period for the ratio. If they were perfectly rational, they wouldn't have had orphans recently, because they would have anticipated the upgrade. The ratio tells you about their past strategies, which they might have tried and abandoned (or will abandon). If they were perfectly rational, there is no reason for the 16/35=45% difference in processing times (based on ratio), I would have thought that F2Pool has slower connectivity, so should be the other way around. If miners were perfectly rational, they would pay attention, in the same way, to the way empty blocks worry users. Data has much variation, and our estimates, by completely different methods, are actually surprisingly close (~10 sec handwaving, ~16 sec empirical), not necessarily contradictory.

Donations to 1SumKArxoEJ1HoGibmj8ygw1DZWYBvjmM
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
July 05, 2015, 10:03:41 AM
Last edit: July 05, 2015, 11:25:24 AM by TPTB_need_war
 #28156

DeathAndTaxes ... where did he go??

A: perhaps death and taxes.  Cheesy

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
July 05, 2015, 10:10:10 AM
 #28157

I see no problem with SPV mining while verifying the previous block. It would also make my above suggestion pointless.

Yes.

Moreover, I don't see why the time spent verifying would be significant. The vast majority of transactions would have been verified by a full node before being included in the block, and then it is just a case of checking the hash, and looking up that the txn was previously mempool verified. The verification time for a block should be insignificant relative to its download time (unless it's a flood attack of new txns by a miner). Or am I missing something?

This was also implicit in my upthread point that the only justification for widespread 0 txn blocks would be bandwidth (propagation) delay.

IBLT purports to improve that by sending less impulse data when announcing the block, but it can't help if the steady state average rate of txns is greater than the bandwidth of the node and it can't stop the collusion of withholding transactions and flooding to force lower bandwidth nodes to be essentially SPV miners. That is why I say it is obfuscation of centralization.

TheRealSteve
Hero Member
*****
Offline Offline

Activity: 686
Merit: 500

FUN > ROI


View Profile
July 05, 2015, 10:25:15 AM
 #28158

is there a way for you to tell what % of blocks have been full over the last 3 wks and compare that to prior going back to say Jan 1?

i'd include those in the 900+ and 720-750 kB range as being full.
Yes, though I'd have to wonder what's special about the last 3 weeks?  BTC China and Antpool increased their max block size a bit before that.  Could also use a different metric for 'full' - e.g. "N% of their apparent maximum".
( Some of the discussion since your post may have made this moot - let me know, I can whip something up regardless )

smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
July 05, 2015, 10:25:35 AM
Last edit: July 05, 2015, 11:08:32 AM by smooth
 #28159

Again I think the heart of it for me personally is that felt Monero doesn't really own anything, other than its own (perhaps smaller than Bitcoin's rather small) community and its refined implementation. In the sense that Python owns its syntax. If you create a JPython you are still helping Python. If you create a BitcoinJ, you are still helping Bitcoin. This is what I meant when I wrote the ecosystem was a "clusterfuck" (or let's say non-ideal). We had developers and communities fighting each other on the same protocol. It felt like copycoins vs. Bitcoin, except in this case none of them were the first and legitimate one.

Yes, that's what happens when you build something and try to launch it with a fraudulent 82% premine, a fake backstory, and an army of shills trying to make it appear popular and established. A clusterfuck. So that is (or more accurately was) a fair characterization, but not one of any of our making, and one that Monero has attempted (with a fair degree of success) to replace with a vibrant and successful community.

I disagree with your last sentence though. Monero is indeed the first legitimate cryptonote coin, which was launched as a minimal fork for the sole reason of getting rid of the fraudulent premine. (Also worth noting that the public face of the cryptonote team welcomed and invited forks, and even released a "coin fork creation kit"; https://cryptonotestarter.org)

Monero has always been a fully public open source project where everyone including the original developers has been (and continue to be) welcome to contribute. For all we know, some of the original developers (who are anonymous, as are many Monero contributing developers) have contributed. We know, for example, that during the chain fork attack last year, the cryptonote group sent a fix (though the community had already by that time developed one anyway).

Quote
One of the signs of leadership is being able to get everyone working together.

You can't necessarily ever get everyone working together. Nevertheless a great many people are indeed working together a year later, and that should say something about the leadership. When you count the core developers, contributing developers to the core project, people working on Monaro-related businesses such as MyMonero and Crypto-Kingdom, mining pools, various independent developers and other significant projects (such as the new Android mobile wallet) there are at least several dozen actual developers working on various aspects of it, along with many non-developers contributing in their own ways too.

I will leave to others whether that constitutes good leadership, but my opinion should be fairly obvious.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
July 05, 2015, 10:27:32 AM
 #28160

Oh my pink face  Embarrassed. I just stumbled across what I wrote on June 30, 2011...I was obviously distracted, not focused, and naive about cryptography, just picked up some random forum post I landed on via Google. Actually I was correct, except my pessimism about the possibility for anonymity as a solution.

Quote
BitCoin is socialist and not (and no online curency can be) anonymous

http://www.bitcoin.org/

The fundamental problem is that any online currency either requires a centralized trust authority which is subject to govt regulation, or a majority vote of decentralized authorities which is just socialism and the antithesis of what makes gold and silver money (he who holds the gold makes the rules, no third party authority or majority vote). I had come to this conclusion a long time ago in the Precious Metals forum during my analysis of whether an online currency (potentially backed by gold and silver) could survive govt retribution.

BitCoin can be defeated by a hacker who puts a virus on a majority of computers using BitCoin, or a govt legislation that requires every computer sold to run a firmware program that defeats it (even if a minority will remove the firmware illicitly):
http://forum.bitcoin.org/index.php?topic=12435.msg172811#msg172811

Thus the BitCoin algorithm has an attack vector, which encourages govt regulation of our computers.

No anonymity on the internet:
http://en.wikipedia.org/wiki/Bitcoin#Anonymity

Pages: « 1 ... 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 [1408] 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 ... 1557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!