Bitcoin Forum
July 24, 2017, 01:03:19 PM *
News: Due to BIP91, it would starting now be prudent to require 5 times more confirmations than usual before trusting transactions.
 
   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 ... 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 [518] 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1936122 times)
FNG
Hero Member
*****
Offline Offline

Activity: 588


View Profile
August 08, 2014, 07:39:53 AM
 #10341

Nikkei closed down 3%

 Shocked
1500901399
Hero Member
*
Offline Offline

Posts: 1500901399

View Profile Personal Message (Offline)

Ignore
1500901399
Reply with quote  #2

1500901399
Report to moderator
1500901399
Hero Member
*
Offline Offline

Posts: 1500901399

View Profile Personal Message (Offline)

Ignore
1500901399
Reply with quote  #2

1500901399
Report to moderator
1500901399
Hero Member
*
Offline Offline

Posts: 1500901399

View Profile Personal Message (Offline)

Ignore
1500901399
Reply with quote  #2

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

Posts: 1500901399

View Profile Personal Message (Offline)

Ignore
1500901399
Reply with quote  #2

1500901399
Report to moderator
1500901399
Hero Member
*
Offline Offline

Posts: 1500901399

View Profile Personal Message (Offline)

Ignore
1500901399
Reply with quote  #2

1500901399
Report to moderator
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
August 08, 2014, 11:04:34 AM
 #10342

Gavin is on the case, and in style!

https://twitter.com/gavinandresen/status/497543580266004480

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 08, 2014, 11:37:11 AM
 #10343


What's he talking about exactly from a  technical standpoint?
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
August 08, 2014, 11:51:54 AM
 #10344


What's he talking about exactly from a  technical standpoint?

We will need to wait for him to write up a blog summary, but my interpretation is that it is a method of propagating through the network "abbreviated" blocks which will always be the same size no matter how much Bitcoin tx volume occurs (within reason!). The full blocks would follow separately to those nodes which want them, perhaps to be known as "archive" nodes. It means that mining can happen fast on the next block without waiting for the slow propagation and verification of larger and larger blocks. It is a more sophisticated extension of the headers-first proposals.

Fantastic if it can be done. To the moon and all that...

FNG
Hero Member
*****
Offline Offline

Activity: 588


View Profile
August 08, 2014, 12:03:39 PM
 #10345


What's he talking about exactly from a  technical standpoint?

We will need to wait for him to write up a blog summary, but my interpretation is that it is a method of propagating through the network "abbreviated" blocks which will always be the same size no matter how much Bitcoin tx volume occurs (within reason!). The full blocks would follow separately to those nodes which want them, perhaps to be known as "archive" nodes. It means that mining can happen fast on the next block without waiting for the slow propagation and verification of larger and larger blocks. It is a more sophisticated extension of the headers-first proposals.

Fantastic if it can be done. To the moon and all that...
http://www.reddit.com/r/Bitcoin/comments/2cywzg/gavin_tweets_something_importantsounding/cjkewc1
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2324



View Profile
August 08, 2014, 12:07:56 PM
 #10346


What's he talking about exactly from a  technical standpoint?

We will need to wait for him to write up a blog summary, but my interpretation is that it is a method of propagating through the network "abbreviated" blocks which will always be the same size no matter how much Bitcoin tx volume occurs (within reason!). The full blocks would follow separately to those nodes which want them, perhaps to be known as "archive" nodes. It means that mining can happen fast on the next block without waiting for the slow propagation and verification of larger and larger blocks. It is a more sophisticated extension of the headers-first proposals.

Fantastic if it can be done. To the moon and all that...

It would also mean that the current incentive to keep block sizes small due to increased orphaning probability would be removed ... and the block size limit debate is back on the table with more urgency.

Bitcoin Warrior
Newbie
*
Offline Offline

Activity: 16


View Profile
August 08, 2014, 12:15:12 PM
 #10347

thats nor sync, gold never touch bitcoin
i think thats all just at moment,
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 08, 2014, 12:19:03 PM
 #10348


What's he talking about exactly from a  technical standpoint?

We will need to wait for him to write up a blog summary, but my interpretation is that it is a method of propagating through the network "abbreviated" blocks which will always be the same size no matter how much Bitcoin tx volume occurs (within reason!). The full blocks would follow separately to those nodes which want them, perhaps to be known as "archive" nodes. It means that mining can happen fast on the next block without waiting for the slow propagation and verification of larger and larger blocks. It is a more sophisticated extension of the headers-first proposals.

Fantastic if it can be done. To the moon and all that...

It would also mean that the current incentive to keep block sizes small due to increased orphaning probability would be removed ... and the block size limit debate is back on the table with more urgency.

Good point.

But doesn't constructing a huge Merkle Root take longer than a small one?
Carlton Banks
Legendary
*
Offline Offline

Activity: 1708



View Profile
August 08, 2014, 12:32:30 PM
 #10349

Headers-only block propagation could also make some room to examine the effects of reducing the block interval. Who knows, we could end up with 1Mb blocks @ 2 blocks/min

Vires in numeris
BowieMan
Full Member
***
Offline Offline

Activity: 154


Is there life on Mars?


View Profile
August 08, 2014, 02:38:34 PM
 #10350

Gold is like Bitcoin, it also has those rabid movements up and down. I think they're highly influenced by the state of the western economies! The downside of Gold is that its bubbles aren't getting bigger and bigger every time!

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
PRIMEDICE
The Premier Bitcoin Gambling Experience @PrimeDice
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 08, 2014, 03:04:04 PM
 #10351

It would also mean that the current incentive to keep block sizes small due to increased orphaning probability would be removed ... and the block size limit debate is back on the table with more urgency.
No matter how much they optimize block creation, somebody (not necessarily the same entity that does the hashing) has to build the Merkle tree, and whoever they are they can't process an infinite number of transactions per second.

As long as the ability of the network to process transactions isn't infinite, there will be some equilibrium price where the supply curve for transaction processing intersects with the demand curve.

It may just be that the price of transaction processing dropped a few orders of magnitude, which is a good thing.

The ability to provide the same service at a lower price makes the network more useful.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 08, 2014, 03:42:08 PM
 #10352

It would also mean that the current incentive to keep block sizes small due to increased orphaning probability would be removed ... and the block size limit debate is back on the table with more urgency.
No matter how much they optimize block creation, somebody (not necessarily the same entity that does the hashing) has to build the Merkle tree, and whoever they are they can't process an infinite number of transactions per second.

yes, i've been asking about this on Reddit w/o an answer yet.  there must be some finite time required to construct a Merkle Tree where it becomes cumbersome timewise.  the question is, where is that point?

Quote
As long as the ability of the network to process transactions isn't infinite, there will be some equilibrium price where the supply curve for transaction processing intersects with the demand curve.

It may just be that the price of transaction processing dropped a few orders of magnitude, which is a good thing.

The ability to provide the same service at a lower price makes the network more useful.

the other thing i don't understand is doesn't the miner who has received a valid header from another miner still have to wait for the tx's themselves to show up so he can remove them from the UTXO set before constructing the next block?
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 08, 2014, 04:23:40 PM
 #10353

the question is, where is that point?

This is not a question we can answer. The right approach is to build a machine for constantly discovering the answer to that question in real time a.k.a a market.

the other thing i don't understand is doesn't the miner who has received a valid header from another miner still have to wait for the tx's themselves to show up so he can remove them from the UTXO set before constructing the next block?

Presumably you assume the miners have already seen the transactions before they see the Merkle tree, and they've seen the Merkle tree before they see the header.

People who want their transactions processed, and miners who want their headers to propagate, have an incentive to make sure it is so.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 08, 2014, 04:32:54 PM
 #10354

the question is, where is that point?

This is not a question we can answer. The right approach is to build a machine for constantly discovering the answer to that question in real time a.k.a a market.

the other thing i don't understand is doesn't the miner who has received a valid header from another miner still have to wait for the tx's themselves to show up so he can remove them from the UTXO set before constructing the next block?

Presumably you assume the miners have already seen the transactions before they see the Merkle tree, and they've seen the Merkle tree before they see the header.

People who want their transactions processed, and miners who want their headers to propagate, have an incentive to make sure it is so.

i think the UTXO set will have to have a pre-agreed order that will need to be synced amongst all miners in real-time.  then, the successful miner can publish the header hash along with some signal as to how far down in that list he went before he stopped adding tx's.  then, all other miners will know how to verify the published header hash and remove those tx's from the utxo set before moving on to the next block.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 08, 2014, 04:39:40 PM
 #10355

i think the UTXO set will have to have a pre-agreed order that will need to be synced amongst all miners in real-time.
What if the UTXO set itself is a structure that gets merge-mined with the blocks themselves?
flipperfish
Sr. Member
****
Offline Offline

Activity: 334


Dolphie Selfie


View Profile
August 08, 2014, 04:41:09 PM
 #10356

i think the UTXO set will have to have a pre-agreed order that will need to be synced amongst all miners in real-time.  then, the successful miner can publish the header hash along with some signal as to how far down in that list he went before he stopped adding tx's.  then, all other miners will know how to verify the published header hash and remove those tx's from the utxo set before moving on to the next block.

Yes, as I understand it, the trick is the deterministic order. The "signal as to how far down in that list" is the thing gavin tweeted about.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 08, 2014, 04:43:35 PM
 #10357

i think the UTXO set will have to have a pre-agreed order that will need to be synced amongst all miners in real-time.
What if the UTXO set itself is a structure that gets merge-mined with the blocks themselves?

iirc, the utxo set takes up about 75% of RAM required to run a node.  as i run 4 nodes myself, it takes a minimum of 1GB RAM to run smoothly meaning 750MB could be estimated for the utxo set itself.  that's pretty big to be including in a block...
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
August 08, 2014, 04:44:49 PM
 #10358

iirc, the utxo set takes up about 75% of RAM required to run a node.  as i run 4 nodes myself, it takes a minimum of 1GB RAM to run smoothly meaning 750MB could be estimated for the utxo set itself.  that's pretty big to be including in a block...
Not in the block, alongside the block.

Just like when people merge mine Namecoin the nmc blocks aren't included in the btc blocks.
hdbuck
Legendary
*
Offline Offline

Activity: 1260



View Profile
August 08, 2014, 04:45:11 PM
 #10359

i'm not sure it has already been discussed here, but here is two matters that i think might be worth a thought :

NSA's 1996 report talking about minting & cryptocurrencies : http://groups.csail.mit.edu/mac/classes/6.805/articles/money/nsamint/nsamint.htm

BGP hijaking, huge threat to bitcoin?: http://www.wired.com/2014/08/isp-bitcoin-theft/

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 08, 2014, 04:45:12 PM
 #10360

i think the UTXO set will have to have a pre-agreed order that will need to be synced amongst all miners in real-time.  then, the successful miner can publish the header hash along with some signal as to how far down in that list he went before he stopped adding tx's.  then, all other miners will know how to verify the published header hash and remove those tx's from the utxo set before moving on to the next block.

Yes, as I understand it, the trick is the deterministic order. The "signal as to how far down in that list" is the thing gavin tweeted about.

how reliable is a synced utxo set across all miners?
Pages: « 1 ... 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 [518] 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 ... 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!