Bitcoin Forum
December 05, 2016, 12:42:04 PM *
News: Latest stable version of Bitcoin Core: 0.13.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 ... 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 569 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1804588 times)
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


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


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

1480941724
Hero Member
*
Offline Offline

Posts: 1480941724

View Profile Personal Message (Offline)

Ignore
1480941724
Reply with quote  #2

1480941724
Report to moderator
1480941724
Hero Member
*
Offline Offline

Posts: 1480941724

View Profile Personal Message (Offline)

Ignore
1480941724
Reply with quote  #2

1480941724
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480941724
Hero Member
*
Offline Offline

Posts: 1480941724

View Profile Personal Message (Offline)

Ignore
1480941724
Reply with quote  #2

1480941724
Report to moderator
1480941724
Hero Member
*
Offline Offline

Posts: 1480941724

View Profile Personal Message (Offline)

Ignore
1480941724
Reply with quote  #2

1480941724
Report to moderator
FNG
Hero Member
*****
Offline Offline

Activity: 588


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


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



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


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
 #10364

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
 #10365


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
*
Online Online

Activity: 1470



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

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
 #10367

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
 #10368

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
 #10369

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
 #10370

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
 #10371

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
 #10372

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


Dolphie Selfie


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

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
 #10374

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
 #10375

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



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

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
 #10377

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?
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 08, 2014, 04:46:36 PM
 #10378


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



nah, miners who aren't paying attention, maybe.  but not the protocol itself.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 08, 2014, 04:47:11 PM
 #10379

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.

why would you do that?
domob
Legendary
*
Offline Offline

Activity: 936


View Profile WWW
August 08, 2014, 05:29:13 PM
 #10380

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.

why would you do that?

I may be mistaken, but isn't this basically what the "ultimate UTXO pruning" thing is about?  As far as I have heard, it allows new clients to be synced almost immediately (at least a lot faster than when downloading the full chain) with less required trust than SPV clients and the like (or even almost the same trustless-ness as a full node?).  I've never really dived into the details, though.

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
Pages: « 1 ... 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 569 ... 1560 »
  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!