Bitcoin Forum

Alternate cryptocurrencies => Altcoin Discussion => Topic started by: mczarnek on May 15, 2014, 03:05:09 AM



Title: Decentralized Timestamp
Post by: mczarnek on May 15, 2014, 03:05:09 AM
So I was discussing this with a friend was wondering if you guys had any input, how would you go about creating a decentralized system that agrees on the current time?

Preferably not Proof of Work.

Thanks.


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 15, 2014, 11:18:32 AM
It is virtually impossible due to Sybil attacks. Bitcoin is as close to a decentralised timestamp system as you will get.


Title: Re: Decentralized Timestamp
Post by: gmaxwell on May 15, 2014, 04:02:27 PM
Using hash-chain mediated common view time transfer, as I wrote in 2011: https://people.xiph.org/~greg/decentralized-time.txt

Quote
Preferably not Proof of Work.
Your question stops being interesting when you start removing the only known solution for strong decentralized consensus— even in the proof of work model an effort to do consensus time probably fails for incentive reasons, but no one knows how to do decenteralized consensus absent the expenditure of work.


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 15, 2014, 04:32:20 PM
So I was discussing this with a friend was wondering if you guys had any input, how would you go about creating a decentralized system that agrees on the current time?

Preferably not Proof of Work.

Thanks.

Why can't nodes simply use their own server time, adjust to GMT, and reject messages from other
nodes that are not matching (within a margin of error)?


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 16, 2014, 01:54:55 AM
It is virtually impossible due to Sybil attacks. Bitcoin is as close to a decentralised timestamp system as you will get.

nope, can be done.  I have a working model.  see:  http://www.stanford.edu/class/cs240/readings/lamport.pdf

if you review that paper maybe we can discuss how to do this, otherwise I'll save it for later.

later friends!  -bm


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 16, 2014, 01:59:03 AM
Using hash-chain mediated common view time transfer, as I wrote in 2011: https://people.xiph.org/~greg/decentralized-time.txt

Quote
Preferably not Proof of Work.
Your question stops being interesting when you start removing the only known solution for strong decentralized consensus— even in the proof of work model an effort to do consensus time probably fails for incentive reasons, but no one knows how to do decenteralized consensus absent the expenditure of work.

Quote
Participating nodes would sample RF noise on some agreed band(s) being
emitted by the Sun and continually record it, with their sampling clock
being driven by their stable local oscillator. Nodes would then publish
timestamped recent fragments of this signal. Peers would then perform a
cross-correlation between the fragments and their own timestamped recordings
in order to find the offset. Only nodes which can concurrently observe the
sun can actively participate in the agreement, but because the local
oscillators are relatively stable this should not prevent good long term
stability. (Effectively your clock would be corrected in the daytime and
free run at night).

Greg, I usually like your ideas... but wow.

-bm


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 16, 2014, 02:06:43 AM
oh and decentralized timestamping CAN BE DONE and it CAN BE ADDED TO NXT.     ::)

-bm


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 16, 2014, 02:17:00 AM
re: specialized hardware that uses the sun.

interesting... but this sounds way harder to implement
than running ASICs farms....possibly so much so that
it would be hard to gain traction at least presently...right?


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 16, 2014, 02:25:38 AM
re: specialized hardware that uses the sun.

interesting... but this sounds way harder to implement
than running ASICs farms....possibly so much so that
it would be hard to gain traction at least presently...right?

you could use some sort of atomic clock to determine objective time and this solves the problem if inaccuracy, but does not solve the problem of FRAUD.

-bm


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 16, 2014, 02:32:40 AM
from an adoption point of view, atomic clocks arent that much better.
anyone can run a bitcoin node from an ordinary computer
and i think might be important.


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 16, 2014, 02:35:04 AM
a commercially available atomic clock chip:  http://www.microsemi.com/products/timing-synchronization-systems/embedded-timing-solutions/components/sa-45s-chip-scale-atomic-clock

so we don't need the sun.  The problem is very specific to our application because in finance there is an incentive to defraud, it's not just a matter of coordination(a problem that has been solved in many different ways) but also a problem of certification.  It's a bit difficult but my concept descends from Vector Clocks.  http://en.wikipedia.org/wiki/Vector_clock

it's not top secret or anything just would rather discuss with an audience who has some familiarity with these problems.

-bm


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 16, 2014, 02:46:05 AM
In NXT for instance they are going to add a BOND system.  Bonds are the basic elementary component of credit systems and they have fairly simple qualities:  A PRINCIPAL, INTEREST, and MATURITY.

If the borrower fails to repay PRINCIPAL + INTEREST at time specified at MATURITY, then you have a DEFAULT.  So naturally how do we measure this event in a block chain?  In some cases loans might have a maturity of a few minutes, how can we make sure that the payment is made before the maturity time?  Can we express maturity in block depth?  Currently our discussions seem to indicate that there are no functional issues with having a loan maturity expressed in terms of block depth, the only drawback is that the borrower or lender might find these terms difficult to manage, but generally they work.

-bm


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 16, 2014, 03:44:48 AM
a commercially available atomic clock chip:  http://www.microsemi.com/products/timing-synchronization-systems/embedded-timing-solutions/components/sa-45s-chip-scale-atomic-clock

so we don't need the sun.  The problem is very specific to our application because in finance there is an incentive to defraud, it's not just a matter of coordination(a problem that has been solved in many different ways) but also a problem of certification.  It's a bit difficult but my concept descends from Vector Clocks.  http://en.wikipedia.org/wiki/Vector_clock

it's not top secret or anything just would rather discuss with an audience who has some familiarity with these problems.

-bm

Sure.... You meanies only take no for an answer   ;)



Title: Re: Decentralized Timestamp
Post by: mczarnek on May 16, 2014, 04:38:59 PM
It is virtually impossible due to Sybil attacks. Bitcoin is as close to a decentralised timestamp system as you will get.

nope, can be done.  I have a working model.  see:  http://www.stanford.edu/class/cs240/readings/lamport.pdf

if you review that paper maybe we can discuss how to do this, otherwise I'll save it for later.

later friends!  -bm


Very nice!  Will have to further review this paper later.


oh and decentralized timestamping CAN BE DONE and it CAN BE ADDED TO NXT.     ::)

-bm

Read my mind :)

In fact I think it was one of your posts that lead mthcl to start talking about it with us.. which lead to this post.


Title: Re: Decentralized Timestamp
Post by: gmaxwell on May 16, 2014, 05:01:37 PM
nope, can be done.  I have a working model.  see:  http://www.stanford.edu/class/cs240/readings/lamport.pdf
I'm familiar with that paper and have linked to it on the forum before. Note that Lamport is talking about a distributed system, not a decenteralized one.  As I recall process he describes is not byzantine robust, requires a jamming proof broadcast network, and does not have anonymous membership (the players must be selected in advance, so it cannot meet our definitions of decenteralized— in particular it needs a consensus arbitrary ordering of player identities to break ties).

As far as POS goes, I've not seen anyone tender a solution to the nothing at stake problem, and so I still consider it non-viable for a decentralized consensus. PPC makes it work by requiring POW and using centralized block signatures. NXT was previously making it 'work' by not releasing the complete source to their software, I haven't checked lately.  So far POS schemes all suffer from attacks like former quorums (e.g. people who held coins at some point in the past) can costlessly replace the history by forking off from a point where they did have a quorum after they no longer do, and from things like the optimal income producing mining strategy is to mine all forks (because there is ~0 marginal cost in mining a fork) instead of a single one. Schemes like honesty bonds do not help a node decide between two different networks— the real one and a simulated one, and cannot punish someone if they perform the attack after exiting the network completely.


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 16, 2014, 05:09:53 PM
gmaxwell,

  could you point us to some sort of an official statement on the 'nothing-at-stake problem'?  No one seems to really be all that clear on what this problem actually is.  From what I was told the person who first proposed it took it down?  So far I've heard many different takes on this particular subject.

  a big problem for NXT is that the stakeholders in the project are very decentralized, so their 'PR' seems a bit off at times.  There's really no one to handle these kinds of questions and an adopter/investor really has no where to get to them resolved.

thanks, -bm


Title: Re: Decentralized Timestamp
Post by: ArnoldChippy on May 16, 2014, 09:31:04 PM
Don't the GPS satellites transmit an accurate time signal that could be used for this purpose?


Martin


Title: Re: Decentralized Timestamp
Post by: gmaxwell on May 16, 2014, 10:02:27 PM
could you point us to some sort of an official statement on the 'nothing-at-stake problem'?  No one seems to really be all that clear on what this problem actually is.  From what I was told the person who first proposed it took it down?
You've been told some pretty weird stuff then. Nothing has been taken down, and it's not that complicated a point.

In POW to contribute to a consensus you must burn a resource, which means you must make an exclusive choice among all the possible consensus you could contribute to, to the exclusion of all others... and for your effort to not be wasted you should be spending it on the chain you think most likely to survive.  In pure POS schemes, there is no such exclusivity created.  This leads to fun outcomes like old stake holders can exit the system (sell their coins) and then sell their old keys to people go fork off the chain at a point in the past, at no cost to themselves. Someone who is later handed two histories— the real one and the simulated one— cannot distinguish them, they can tell— perhaps— that someone was naughty, but that doesn't help them decide which chain is the good one.  There are a number of other related implications.  A number of different modifications have been proposed, but so far all of them seem to be obfuscation and not actually fix the underlying issue, which seems a bit fundamental.

You can read more about this in Section 5 of https://download.wpsoftware.net/bitcoin/asic-faq.pdf

PPC was attacked utilizing this fact the moment POS mining became possible on it— a savvy miner tried all possible forks finding a sequence of forks which selected their stake as the winning stake as much as possible. PPC prevented this with block signing and discouraged it by hard forking the protocol so that POW blocks were required.

Don't the GPS satellites transmit an accurate time signal that could be used for this purpose?
GPS is unauthenticated. Any local-to-you jammer can spoof it with nothing more complex than a USRP and some software. It's also run by US space command, and the US has been quite up front that they are willing to manipulate or disrupt the signal to achieve military objectives, they're able to perform geo-targeted alterations of the signal too.  It's pretty useful on average, but it's not a secure solution by itself.


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 16, 2014, 10:32:45 PM
DeathandTaxes has been schooling us on the same issue in the last 24 hours, I believe.
He makes some good distinctions, as usual:

see here:  
 
https://bitcointalk.org/index.php?topic=27787.80


Title: Re: Decentralized Timestamp
Post by: Cryddit on May 17, 2014, 03:10:08 AM
gmaxwell,

  could you point us to some sort of an official statement on the 'nothing-at-stake problem'?  No one seems to really be all that clear on what this problem actually is.  From what I was told the person who first proposed it took it down? 

The central issue with proof-of-stake is that when the chain forks, the stakeholders on the left side of the fork, with very few exceptions, are also stakeholders on the right side of the fork.  Whichever fork wins, they still have their stake.  In fact, they have an incentive to use it to mine both sides of the fork at once.  There's literally no rational reason for them not to; whichever fork eventually fails is eliminated from history, but until they know for sure which one that's going to be, why would they stop mining it?  And as a result of that dysfunction, why does a choice between forks ever get made at all?

Proof-of-work is the expenditure of a finite resource (hashing power) in real time.  You cannot use the same hashing power to support both sides of a fork; you are forced by physics to choose one side or the other, and therefore a decision on the local level perforce actually gets made - leading to a decision on the wider level.

The nothing-at-stake problem can be overcome by GHOST protocol or similar; it must not be possible to support one side of a fork without your repudiation or withdrawal of support being visible to the other. 


Title: Re: Decentralized Timestamp
Post by: gmaxwell on May 17, 2014, 06:38:22 AM
The nothing-at-stake problem can be overcome by GHOST protocol or similar
This is far from clear to me, the obvious formulations of that would seem to have infinite convergence time to me.

You've given a pretty clear explanation of one aspect of the problem— though another one with common causes is costless simulation: e.g. some early large number of stake holders can go fork it off and with no cost produce a simulated chain which a new node cannot distinguish from the original. They can do this at any point, even after exiting the system, years later— so it doesn't seem possible that any inside-system incentives can prevent them from doing so.


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 17, 2014, 10:38:37 AM
The GHOST protocol seems to be able to mitigate real time forking (although I haven't analysed in depth the assumptions of that model) however it is not effective against historical forking.

Their are ways of mitigating historical forking but none are secure without some unrealistic assumptions. The primary assumption is that a majority of past coin holders will not conspire together to rewrite the history of the chain. That may be true when past coin holders are still holding coins but it falls apart when the coins change ownership over time. I've yet to see any decentralised proposal which is secure against this form of attack without invoking some form of proof of work.

It is important to remember that the purpose of the block chain is to achieve consensus. If consensus is actually achieved via an alternative method (software patches, checkpoints, consensus between coin service providers etc.) then there is little point having a block chain at all and there will likely exist more secure and efficient ways of doing the same thing without a block chain.


Title: Re: Decentralized Timestamp
Post by: Cryddit on May 17, 2014, 04:32:33 PM
The nothing-at-stake problem can be overcome by GHOST protocol or similar
This is far from clear to me, the obvious formulations of that would seem to have infinite convergence time to me.

You've given a pretty clear explanation of one aspect of the problem— though another one with common causes is costless simulation: e.g. some early large number of stake holders can go fork it off and with no cost produce a simulated chain which a new node cannot distinguish from the original. They can do this at any point, even after exiting the system, years later— so it doesn't seem possible that any inside-system incentives can prevent them from doing so.

Hmmm.  That's a fine example of withdrawing your support from a blockchain (by creating an attack chain) without making the repudiation or withdrawal of support visible on that blockchain (because it hasn't happened yet). 

And you're right, the GHOST protocol doesn't address it.  Darn.

There are partial protections such as checkpoints in the downloaded wallet, but the most they can do is limit the length of the 'simulation' or attack chain.


Title: Re: Decentralized Timestamp
Post by: mczarnek on May 19, 2014, 03:00:40 AM
The way Nxt does it is actually quite clever and solves the nothing at stake problem, there is more to it than this but the part of it that I understand is that choosing who forges next is every forger does SHA(last forger public key) Somehow how long ago an account forged and how many nxt owned by that account and information from the last block is factored in as well.  The winner is the one who has the largest hash.

So, in order to crack it, you need to use proof of work in order to find accounts that would have higher hashes for every block along the way.

This would take a network that does the same thing the Bitcoin network does but would be many magnitudes of order greater than the Bitcoin network to hash numbers in order to fast enough determine how an attacker would move around their coins into the right accounts in order to be able to author blocks.  And if it's not enough security, do SHA(SHA()) and you've squared the amount of processing power required by an attacker.  So an attacker would basically have to build a very expensive and long fork faster than the network does these light-weight operations.  He also needs to be able to plan 1440 blocks into the future in order to know where to place these Nxt in order for the network to accept his hash as valid.

There are some other things, such as not allowing block that have timestamps greater than X blocks ago.  And there is some other secret sauce that has been discussed behind the scenes that I'm not going to reveal here.

Point is though, this works in a completely different way to Bitcoin and the nothing at stake problem doesn't apply here because it works so differently.  Also, I believe there aren't 'forks' in the same sense that regularly pop-up as they do in the Bitcoin network because forgers aren't submitting their 'fork' to the network that they can re-write(short of that ultra high processing power), they are submitting their individual block.

Basically we aren't getting much further into the details though because they want to implement it and having working first before telling our competitors the right way to implement POS.  There are a number of people who have reviewed it however and it works.

You want to further discuss it, I recommend checking out this thread: https://nxtforum.org/general/how-does-nxt-fix-the-nothing-at-stake-problem/


Title: Re: Decentralized Timestamp
Post by: gmaxwell on May 19, 2014, 04:25:01 AM
Point is though, this works in a completely different way to Bitcoin and the nothing at stake problem doesn't apply here because it works so differently.
Bitcoin is not a POS coin so it's a bit weird to say that a thing that is completely inapplicable to Bitcoin is inapplicable to your thing because its different from Bitcoin, especially if that reason is "secret sauce".

The simulation example is probably the hardest to convincingly wave away. Say tomorrow half the NXT value holders decide to sell their coin. Six months after that their old NXT keys fall into evil hands. The evil people create a fork of the NXT chain and in seconds mine it up to the current day. How do existing nodes know not to reorg onto the new one? If there is a threshold where they won't reorg, what prevents the malicious parties from producing blocks right at the threshold and making one half of the network stick to one chain, one half to another?  And most importantly, a NXT node that has been offline for seven months comes back, how does it know what chain to follow?  If there are protections here what assumptions do they make and how might they fail? Costless simulation isn't the only problem that arises out of nothing at stake, but its one of the simplest seemingly hard to resolve.

If you're going to not only claim that you've solved those cases but that the solution is both "secret sauce" and trade-off free I'm going to have to say bullshit. If someone else is making those kinds of claims to you and you buy them, I've got a nice bridge to sell you. :)


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 19, 2014, 05:01:15 AM
so whats the ETA on delivery of the secret sauce so we can all taste it?


Title: Re: Decentralized Timestamp
Post by: mczarnek on May 19, 2014, 05:49:15 PM
Point is though, this works in a completely different way to Bitcoin and the nothing at stake problem doesn't apply here because it works so differently.
Bitcoin is not a POS coin so it's a bit weird to say that a thing that is completely inapplicable to Bitcoin is inapplicable to your thing because its different from Bitcoin, especially if that reason is "secret sauce".

The simulation example is probably the hardest to convincingly wave away. Say tomorrow half the NXT value holders decide to sell their coin. Six months after that their old NXT keys fall into evil hands. The evil people create a fork of the NXT chain and in seconds mine it up to the current day. How do existing nodes know not to reorg onto the new one? If there is a threshold where they won't reorg, what prevents the malicious parties from producing blocks right at the threshold and making one half of the network stick to one chain, one half to another?  And most importantly, a NXT node that has been offline for seven months comes back, how does it know what chain to follow?  If there are protections here what assumptions do they make and how might they fail? Costless simulation isn't the only problem that arises out of nothing at stake, but its one of the simplest seemingly hard to resolve.

If you're going to not only claim that you've solved those cases but that the solution is both "secret sauce" and trade-off free I'm going to have to say bullshit. If someone else is making those kinds of claims to you and you buy them, I've got a nice bridge to sell you. :)

No, I'm saying that the algorithm I've discussed should largely provide that protection but is more to come that has been largely discussed but not as openly.

I highly recommend the link I posted as they, especially Come-From-Beyond knows what he is talking about better than I do.

How does Bitcoin solve people downloading the wrong chains?  You could simulate the Bitcoin blockchain from genesis block with less forging power, the difficulty would therefore be lower and people would download the wrong one, right?  Surely the current miner doesn't pass back all the info needed to build a chain from the genesis block every time he solves a hash, right?


Title: Re: Decentralized Timestamp
Post by: gmaxwell on May 19, 2014, 08:47:08 PM
How does Bitcoin solve people downloading the wrong chains?
The new block refers to the prior block. If you don't know the prior block you fetch that too, until you connect to the chain you know. Because the rate of difficulty change is capped a possibly longer chain cannot have difficulty below some threshold (since it can't just be minimum diff blocks), so creating a long bogus fork would be very very expensive. If you did go and make a long bogus fork that was shorter than the real ones, nodes would happily go and fetch them (not saving the blocks) back to where it connects and then realize that it was shorter and just reject it, so the harm would only be wasting bandwidth.  They might download some of the wrong one, but they'd notice when exposed to the right one and deterministically switch to it. This logic is used every day with ordinary 1/2 block forks.

If there ever were a large number of attacks trying to waste nodes bandwidth with expensively created short forks— it's possible to construct log() scale proofs of a blockchains' whole difficulty... we need to have them for some other applications in any case, and they could be employed there.. but considering the cost of the attack and the minimal effects, I doubt that will ever be required.


Title: Re: Decentralized Timestamp
Post by: DeathAndTaxes on May 19, 2014, 09:35:30 PM
How does Bitcoin solve people downloading the wrong chains?  You could simulate the Bitcoin blockchain from genesis block with less forging power, the difficulty would therefore be lower and people would download the wrong one, right?  Surely the current miner doesn't pass back all the info needed to build a chain from the genesis block every time he solves a hash, right?

You can trick a node into download a chain with less difficulty, but you can't trick the node into using it.  The former is a potential resource wasting attack, the later is required to defraud nodes.

This attack is most disruptive against bootstrapping nodes (because the difficulty was low for a very long time) which is why many clients use checkpoints to limit the disruption a node can accomplish.  It is important to understand that even without checkpoints a peer will still be able to determine the chain with the longest difficulty it just may take additional resources.  Bitcoin nodes may be a little too trusting and they can be hardened against "disrputors" but I doubt it will ever become a useful attack.  Even if a node is naive an entire chain of headers it is only 8MB per 100,000 blocks (two years of blockchain history) even modestly "smart" nodes can limit the scope significantly and thus put an upper bound on the resources a disruptive node can waste.


Title: Re: Decentralized Timestamp
Post by: DeathAndTaxes on May 19, 2014, 09:51:40 PM
The way Nxt does it is actually quite clever and solves the nothing at stake problem, there is more to it than this but the part of it that I understand is that choosing who forges next is every forger does SHA(last forger public key) Somehow how long ago an account forged and how many nxt owned by that account and information from the last block is factored in as well.  The winner is the one who has the largest hash.

Saying you know something is solved because of "somehow" kinda implies you don't know it is solved right? :)

The network can't require a specific account solve a given block as if it did then it would be easy to halt the chain by just not solving a block when it is your turn.  The network instead favors one block over another one at a given height.  However what happens when both chains have blocks that are worse than the block on the other chain at a given height.  Ultimately the attacker (which had 51% of the stake at the point of the split) will build the best chain overall despite each chain having better or worse blocks at any given height.  

Does the secret sauce in NXT prevent a 51% attack by a stakeholder who had a majority of the stake but no longer has it?  Maybe.  Saying "somehow" or "secret stuff" makes it stronger is hardly compelling though. No explanation of what is publicly available provides a credible reason why the network can't be attacked.  If it really does solve it then eventually it will be publicly available and clear to everyone right?


Title: Re: Decentralized Timestamp
Post by: gmaxwell on May 19, 2014, 10:31:31 PM
Does the secret sauce in NXT prevent a 51% attack by a stakeholder who had a majority of the stake but no longer has it?  Maybe but saying "somehow" isn't sufficient.  No explanation of what is publicly available provides a credible reason why the attack does not work.  Claiming it is solved based on what is not publicly available is well not very useful.  If it really does solve it then eventually it will be publicly available and clear to everyone right?
A key point here isn't that I believe it's impossible— it's that I believe its impossible absent some trade-off— some other attack the system becomes vulnerable to, for example— or consideration/cost, or assumption (e.g. that no past majority of shareholders will ever act against the interest of the system, even if they've long since left it), so what exactly is that tradeoff?  Keeping the solution secret also implies keeping the vulnerabilities it creates secret, which means that people will be all the more exposed to them.


Title: Re: Decentralized Timestamp
Post by: dogisland on May 20, 2014, 12:18:14 PM
The way Nxt does it is actually quite clever and solves the nothing at stake problem, there is more to it than this but the part of it that I understand is that choosing who forges next is every forger does SHA(last forger public key) Somehow how long ago an account forged and how many nxt owned by that account and information from the last block is factored in as well.  The winner is the one who has the largest hash.

That's not how I understand it from looking at the code. You don't so much choose who forges next, rather the node can decide wether a block is valid or not.

For the block to be excepted.

1. Hash the hash of the previous block.
2. Take the first six bytes of that. Let's call that rnd_selector
3. Take the current time since the last block in millis i.e. 100000
4. Take the effective balance of the account that generated the block.

If balance * time_in_millis > rnd_selector then the block is valid.

Code here https://bitbucket.org/JeanLucPicard/nxt/src/046e59e4df43309a37c2789efd39dba4a873bbe2/src/java/nxt/Generator.java?at=master#cl-160

Basically any account that meets the above criteria can generate the block, if no one can (or someone is offline)  time_in_millis will grow and eventually someone will be able to generate the block.

So to build a competitive chain in NXT, I would have to alter the block message so that rnd_selector keeps on selecting one of my accounts.

The above was drawn from the code so perhaps one of the NXT guys would clarify if this is inaccurate.



Title: Re: Decentralized Timestamp
Post by: telepatheic on May 20, 2014, 01:47:14 PM

For the block to be excepted.

1. Hash the hash of the previous block.
2. Take the first six bytes of that. Let's call that rnd_selector
3. Take the current time since the last block in millis i.e. 100000
4. Take the effective balance of the account that generated the block.

If balance * time_in_millis > rnd_selector then the block is valid.

My understanding based on this code (https://github.com/Telepatheic/nxt2/blob/master/src/java/nxt/Generator.java) is that I can sign a new block if:

base_target * my_balance * time_in_millis > SHA256(previous_block_signature + my_public_key)

So you can very easily iterate through thousands of possible current block signature such that it is guaranteed that you will be the person able to mine the following block. Since the whole process is transparent (public keys and balances are known to everyone), a moderate amount of computation power and coins assures that once you get to create one block you can sign all the blocks following it.

I'm not an NXT developer so I may be wrong.


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 20, 2014, 02:37:11 PM

For the block to be excepted.

1. Hash the hash of the previous block.
2. Take the first six bytes of that. Let's call that rnd_selector
3. Take the current time since the last block in millis i.e. 100000
4. Take the effective balance of the account that generated the block.

If balance * time_in_millis > rnd_selector then the block is valid.

My understanding based on this code (https://github.com/Telepatheic/nxt2/blob/master/src/java/nxt/Generator.java) is that I can sign a new block if:

base_target * my_balance * time_in_millis > SHA256(previous_block_signature + my_public_key)

So you can very easily iterate through thousands of possible current block signature such that it is guaranteed that you will be the person able to mine the following block. Since the whole process is transparent (public keys and balances are known to everyone), a moderate amount of computation power and coins assures that once you get to create one block you can sign all the blocks following it.

I'm not an NXT developer so I may be wrong.


What do you mean by iterating through thousands of possible current block signatures?


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 20, 2014, 03:02:59 PM
What do you mean by iterating through thousands of possible current block signatures?

Signatures are dependent on the data they are signing and my public key, my public key is fixed but the data I am signing is not. I can add and remove transactions to the block to change the output of the signature. (Technically with ECDSA signatures you don't even need to do that, you just change the nonce used in signing to get a different signature)


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 20, 2014, 03:06:14 PM
Signatures are dependent on the data they are signing and my public key, my public key is fixed but the data I am signing is not. I can add and remove transactions to the block to change the output of the signature. (Technically with ECDSA signatures you don't even need to do that, you just change the nonce used in signing to get a different signature)

The generation signature only depends on the previous block generation signature and your public account number. Nothing more.

Part of the generation signature (called hit) is used to determine a queue of forgers. First in this queue is allowed to forge. If he did not, it is the turn of the second in the queue and so on.


Title: Re: Decentralized Timestamp
Post by: DeathAndTaxes on May 20, 2014, 03:35:09 PM
Signatures are dependent on the data they are signing and my public key, my public key is fixed but the data I am signing is not. I can add and remove transactions to the block to change the output of the signature. (Technically with ECDSA signatures you don't even need to do that, you just change the nonce used in signing to get a different signature)

The generation signature only depends on the previous block generation signature and your public account number. Nothing more.

In a double spend attack (including a "51% attack) the attacker would be the one generating the sequence of blocks.  That means each block relies on the prior block also made by the attacker.  The attacker signs a block and if it doesn't allow him to forge the next block, just keeps resigning it until it does (as pointed out a single digest can have an infinite number of unique signatures by changing the k value). The attacker attempts signatures until he produces a one which allows him to sign the next block as well.  The attacker then moves on to the next block.  If this seems kind of like a PoW it is.

Quote
Part of the generation signature (called hit) is used to determine a queue of forgers. First in this queue is allowed to forge. If he did not, it is the turn of the second in the queue and so on.

The attacker won't be publishing his chain until it is longer. As long as one of his accounts is valid for signing the next block (and thus somewhere in the queue even last) there will be nobody ahead of him in the queue that knows about the block.  The network doesn't require a specific signer from the queue be used, it just favors a higher signer over a lower one but all signers are equally valid.  If the attacker had* >51% of the network stake e will produce the longest/best chain.  Note: it isn't actually a "queue" but this doesn't materially change the scenario.

As a side note: deterministic (or quasi deterministic) signing/minting/forging is an interesting idea.  It has some advantages but it isn't some magical 51% proof shield and the "nothing at risk" issue around PoW remains unchanged when compared to other PoS systems.

* It is "had" not "has" because in PoS the critical resource is not a physical item, it is a record in the blockchain. A miner who no longer has any hashpower can no longer mine but a forger who had but no longer has a stake can forge a parallel chain starting from where he had the stake and double spending the tx resulting in him losing the stake. An attacker with 51% of the stake as of block X can sell that stake and still perform a 51% attack starting from block X using the stake he had but no longer has on the main chain.


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 20, 2014, 04:09:55 PM
A 51% attacker would be the one generating the previous block generation signature.  If the signature doesn't produce an output that allows him to sign the next block he just changes the k value and generates a new signature.  A good CPU can do 40,000 ECDSA signatures a second (per core).  When he finds one that allows one of his accounts (51% of the stake) to sign the next block he moves on to the next block.

The attacker doesn't even need a 51% stake. They only need a small stake, once you can forge once, you can ensure that you will always gets to forge the next block (if you have enough computational power), regardless of how small your stake is. I can easily see this attack being possible with 0.1% stake and a standard processor.

As a side note: deterministic (or quasi deterministic) signing/minting/forging is an interesting idea.  It has some advantages (outside of a 51% attack) if combined with a PoW.  It would make long reorgs with a minority of the hashrate more difficulty to achieve which means confirmations have more "weight".  It also allows "legit" miners to achieve consensus quicker.  In the case where two miners produce blocks at the same block height it could provide a fair and deterministic manner for all nodes to choose one over the other. If miners are confident that 51% of the network follow these rules then they would be best served by working on the "best" block not just the first one.  It is beneficial in a split to get the network behind a single chain as quickly as possible (orphaned work is simply wasted work and reduces effective network security).  The full implications both good and bad should be looked at more closely.  It isn't however some magical 51% proof shield and the "nothing at risk" issue around PoW remains unchanged when compared to other PoS systems.

The problem is that you are still vulnerable to historic attacks. Whilst doing analysis for conceptcoin I have found that deterministic proof of stake (even where the mechanism to select who gets to sign each block is unaffected by the actions of the forgers/miners) is still vulnerable to people signing two blocks at a given block height and releasing one of those blocks whilst keeping one hidden to build an attacking chain in the future. Whilst clients who are always online can tell the difference between the real and fake chain, new clients can't.

One way to tell them apart is by assigning work to the chain, this work does not decide who gets to sign blocks. I have proposed a scheme where when a block is being signed it must optionally include a piece of work which is as close to the previous block hash as possible. This work doesn't have to be produced by the signer themselves, everyone submits work to the network to show that they endorse a particular block. It is in the interest of the honest block signers to include the maximum amount of work in their blocks in order to prevent attacks.

Now new clients can see which chain is more likely to be the real one by measuring the cumulative work included in each chain. This successfully decouples proof of work from the rewards handed out, people do work as they feel necessary to secure the network. The problem is without direct economic incentives, the amount of work done and hence security may be very low.


Title: Re: Decentralized Timestamp
Post by: DeathAndTaxes on May 20, 2014, 04:27:36 PM
The attacker doesn't even need a 51% stake. They only need a small stake, once you can forge once, you can ensure that you will always gets to forge the next block (if you have enough computational power), regardless of how small your stake is. I can easily see this attack being possible with 0.1% stake and a standard processor.

I agree with the fact that it can be attacked with less than 51% stake.  How little stake can be used depends on a couple of factors.  The time since last signing and balance are weighted in the "difficulty" of finding a hash so I am not comfortable putting an exact value on how little stake can be used.  That would require some simulations. 

In general though one could say that the structure allows a forger (any forger) to use computing power as a proxy for stake.  The effective share of the network is dependent on not just what share of the stake one has but also what share of the computing power.

While NXT claims to not be PoW if forgers aren't already using computing power to boost their returns they will.  Even non malicious miners would have no incentive to not increase their computing power in order to boost their forging rate.

Quote
Quote
As a side note: deterministic (or quasi deterministic) signing/minting/forging is an interesting idea. ... The full implications both good and bad should be looked at more closely.
The problem is that you are still vulnerable to historic attacks. ...

That is a good point.  I agree and it requires some careful analysis.  I do think it an interesting idea and has some potential.  On your idea of cummulative work it may be possible to incorporate a way to compensate those worker.  I also believe despite my reservations about PoS that there is some way it can be used in conjunction with PoW to raise the cost of an attacker.  PoW for Bitcoin is already beyond the point where any economic attack is possible however there is the non-economic attack.  The network will continue to grow and as miners become more efficient ($/GH and J/GH) the cost for an attacker will rise but eventually margins will be paper thin and further improvements will be limited to the growth of the reward (Moore's law doesn't make the network more secure as it is kinda like GH inflation).  I believe PoS could be used to raise the cost for an attacker further.  To date all the concepts I have sketched out have limitations I a find unacceptable but I believe there is a solution. Imagine if someday the hardware cost to attack the network was $5B but it also required another $50B in stake as well.


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 04:42:38 PM
I believe PoS could be used to raise the cost for an attacker further.  To date all the concepts I have sketched out have limitations I a find unacceptable but I believe there is a solution. Imagine if someday the hardware cost to attack the network was $5B but it also required another $50B in stake as well.

Here you are admitting that Bitcoin as it stands has a significant weakness.

-bm


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 20, 2014, 04:55:39 PM
I agree with the fact that it can be attacked with less than 51% stake.  How little stake can be used depends on a couple of factors.  The time since last signing and balance are weighted in the "difficulty" of finding a hash so I am not comfortable putting an exact value on how little stake can be used.  That would require some simulations.  

In general though one could say that the structure allows a forger (any forger) to use computing power as a proxy for stake.  The effective share of the network is dependent on not just what share of the stake one has but also what share of the computing power.

NXT is completely transparent, that is you know all the public keys of the potential forgers. This allows you to know for certain if you will be the next person to be able to sign the block. To do this you have to calculate the required time in milliseconds that each public key on the network would exceed the target threshold. Admittedly this is computationally expensive. You have to compute a signature then check all the public keys to see if any of them would beat you, thankfully you can simply iterate the signature  until you have a very high likelihood of being able to sign the next block then check all the public keys to verify that you can definitely sign the next block. This will mean the next block will occur quicker than normal and therefore base_target will be reduced (not exactly sure how often it is recomputed) making the time between blocks larger and giving you more time to do your computations in order to guarantee the next block.


Title: Re: Decentralized Timestamp
Post by: gmaxwell on May 20, 2014, 05:31:19 PM
I believe PoS could be used to raise the cost for an attacker further.  To date all the concepts I have sketched out have limitations I a find unacceptable but I believe there is a solution. Imagine if someday the hardware cost to attack the network was $5B but it also required another $50B in stake as well.
Here you are admitting that Bitcoin as it stands has a significant weakness.
All things are subject to attacks, to make them stronger one need to be honest about them. Bitcoin assumes that the majority of the energy expended on its POW is not controlled by a byzantine attacker. Maybe there are things that can be twiddled to make the costs of attack higher?  But that isn't something that comes quickly or easily— most of the times tweaks increase the cost of one already effectively unachievable attack but do so at the expense of opening up a new weakness which is currently absolutely precluded.

Talking frankly about attack costs doesn't mean that anything is weak on an absolute scale.  By contrast, the systems where their authors claim there exists no attacks that they can imagine are almost certantly intolerable insecure since a lack of attacks— even infeasible ones that we can be comfortable with— means that there is either indifference to security, inadequate understanding of their own system, or simply a massive failure of imagination— any of which could be hiding quite serious attacks.


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 20, 2014, 05:35:11 PM
I believe PoS could be used to raise the cost for an attacker further.  To date all the concepts I have sketched out have limitations I a find unacceptable but I believe there is a solution. Imagine if someday the hardware cost to attack the network was $5B but it also required another $50B in stake as well.

Here you are admitting that Bitcoin as it stands has a significant weakness.


Of course bitcoin has weaknesses, to date very little modelling of how bitcoin really works economically has been done. What happens if huge transaction fees (>1000BTC) are sent to the network, what happens if you convince 50% of the network to lease you their miners at double the market rate and what happens when market influenced transaction fees dominate the block rewards.

Bitcoin is based on the assumption that no one would ever lease out hashing power because it is always beneficial to reap all future returns rather than take a short term gain where an attacker could harm the network and perform a double spend. But people do lease out hashing power because they believe that attackers won't be able to lease out 50% of the machines and perform an attack. (Is that a valid assumption? How do we tell how many machines are currently used by attacking parties?)

An attacker with 10,000 BTC could hire enough hashing power to perform a double spend for lets say 1000BTC (probably a lot less than this in reality if miners didn't mind leasing you hashing power), the other 9,000 BTC can be double spent such that the attacker ends up with 9000BTC of cash/goods/services and 9000BTC of bitcoin. The attacker has increased in worth by 8000BTC, the miners on average have increased in worth by (1000BTC - work done producing orphaned blocks) and a lot of merchants/exchanges/service providers are out of pocket by 9000BTC.


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 20, 2014, 05:36:00 PM
I believe PoS could be used to raise the cost for an attacker further.  To date all the concepts I have sketched out have limitations I a find unacceptable but I believe there is a solution. Imagine if someday the hardware cost to attack the network was $5B but it also required another $50B in stake as well.
Here you are admitting that Bitcoin as it stands has a significant weakness.
All things are subject to attacks, to make them stronger one need to be honest about them. Bitcoin assumes that the majority of the energy expended on its POW is not controlled by a byzantine attacker. Maybe there are things that can be twiddled to make the costs of attack higher?  But that isn't something that comes quickly or easily— most of the times tweaks increase the cost of one already effectively unachievable attack but do so at the expense of opening up a new weakness which is currently absolutely precluded.

Talking frankly about attack costs doesn't mean that anything is weak on an absolute scale.  By contrast, the systems where their authors claim there exists no attacks that they can imagine are almost certantly intolerable insecure since a lack of attacks— even infeasible ones that we can be comfortable with— means that there is either indifference to security, inadequate understanding of their own system, or simply a massive failure of imagination— any of which could be hiding quite serious attacks.

gmaxwell, not sure if you stated elsewhere, but what is your opinion of DECOR?


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 05:40:38 PM
An attacker with 10,000 BTC could hire enough hashing power to perform a double spend for lets say 1000BTC (probably a lot less than this in reality if miners didn't mind leasing you hashing power), the other 9,000 BTC can be double spent such that the attacker ends up with 9000BTC of cash/goods/services and 9000BTC of bitcoin. The attacker has increased in worth by 8000BTC, the miners on average have increased in worth by (1000BTC - work done producing orphaned blocks) and a lot of merchants/exchanges/service providers are out of pocket by 9000BTC.

this problem is compounded by the Color Coins technologies that carry asset notes on the BTC block chain.  It's going to make such an attack practically inevitable.

-bm


Title: Re: Decentralized Timestamp
Post by: DeathAndTaxes on May 20, 2014, 05:49:10 PM
Here you are admitting that Bitcoin as it stands has a significant weakness.

This kind of shit makes me just not want to post at all.  No it isn't an admission to anyone who can read.  All security models involve assumptions upon which they derive their strength.  The assumption for Bitcoin is that the attacker will not gain 51% of the network hashrate.  If that assumption is flawed then the model can be attacked.  Likewise any other security model will involve different assumptions possible ones which are easier for an attacker to invalidate.

You will notice the words "I believe", it isn't "I know". No alternative is going to be a magic bullet which eliminates all weaknesses and creates no new ones.   It is entirely possible that I am <gasp> wrong and that there is no such alternative along those lines that would result in an overall stronger network.  Security is ALWAYS about compromise.  

Guess what I can solve the "51% attack" right now.  I will give you this model for free.  A single central authority accepts transactions, verifies them, and publishes the results in the form of a ledger and diff.  These results can be verified cryptographically by any user of the network.  Transactions can be verified within seconds, nodes don't need to maintain more than a minimal amount of historical records and an attacker that isolates a node can't lie to the node it can only block information.   No amount of computing power could allow an attacker to break that system (assuming the cryptographic primitives remain strong).  It isn't 51% proof it is 100% proof.  Of course that trades the potential for an attacker to gain the majority of the computing power for the potential for the central authority to be untrustworthy.  That tradeoff is not worth it but it does "solve" most of the major limitations of the Bitcoin protocol.   Feel free to use it.

Do you get tired of being a shill?  Don't you ever just want to think and discuss?  Why not just read the post and agree or disagree without looking for some angle to exploit?  Don't you find it tedious and small?  At one time this forum (especially this section of the forum) was a place to learn, think and explore.  Lots of healthy debate, discourse, and sometimes it got heated but it was about learning.  I guess that is dead now.  Honestly I don't give a shit anymore.  This will be my last post.

On edit: edited for clarity.


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 05:55:06 PM
Here you are admitting that Bitcoin as it stands has a significant weakness.

This kind of shit makes me just not want to post at all.  No it isn't an admission like that.  All security models involve assumptions.  The assumption for Bitcoin is that the attacker will not gain 51% of the network hashrate and that gaining that would be prohibitively expensive.   You will notice the words "I believe", it isn't "I know".  An alternate security model will be a tradeoff.  There is no guarantee the modified assumptions will make the network more secure.  Security is ALWAYS about compromise.  The system which is most secure from an attacker with significant resources would be where an absolute central authority that manages the network.  No 51% is possible but you now need absolute trust in the central authority.  Although it solves one problem it creates another and I wouldn't consider that an acceptable tradeoff..

tantrums aside,

#1) It's been established that an attacker needs far less than 51% of the hashing power.

#2) Hashing power is now a Liquid Commodity, as in it can readily trade hands.  This also has the effect of reducing the price of said hashing power.  Staging and executing an attack does not even require hardware procurement, the entire thing could be executed from a single internet connection anywhere in the world + a modest amount of capital.

#3) the point I keep raising- the PAYOFF for such an attack is going to increase exponentially due to Color Coins, Counterparty, etc.

it seems whenever anyone raises these points some people on this forum have a fit.

-bm


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 20, 2014, 05:56:25 PM
Here you are admitting that Bitcoin as it stands has a significant weakness.

This kind of shit makes me just not want to post at all.  No it isn't an admission like that.  All security models involve assumptions.  The assumption for Bitcoin is that the attacker will not gain 51% of the network hashrate and that gaining that would be prohibitively expensive.   You will notice the words "I believe", it isn't "I know".  An alternate security model will be a tradeoff.  There is no guarantee the modified assumptions will make the network more secure.  Security is ALWAYS about compromise.  The system which is most secure from an attacker with significant resources would be where an absolute central authority that manages the network.  No 51% is possible but you now need absolute trust in the central authority.  Although it solves one problem it creates another and I wouldn't consider that an acceptable tradeoff.

Do you get tired of being a shill?  Don't you ever just want to think and discuss?  Why not just read the post and agree or disagree without looking for some angle?  Don't you find it tedious and small?  At one time this forum (especially this section) was a place to learn, think and explore.  I guess that is dead now.  Honestly I don't give a shit anymore.  This will be my last post.

This is too bad that you're losing patience, because I was enjoying the
conversation and we need people like you who really know what
they are talking about in the discussion.

Competing cryptocurrencies are potentially disruptive to bitcoin, and
Its no secret bluemeanie is part of the NXT development team, so
I would suggest not to take it personally.  I wouldn't quite agree
he is shilling.

This is bluemeanie's job so to speak... to challenge us.
Whether or not his motive is promote NXT, we should
try to have the discussion. 



Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 05:58:09 PM

This is too bad that you're losing patience, because I was enjoying the
conversation


and he knows that- that's what's making him angry.

-bm


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 20, 2014, 06:01:38 PM
this problem is compounded by the Color Coins technologies that carry asset notes on the BTC block chain.  It's going to make such an attack practically inevitable.

-bm

Also satoshi didn't envisage mining like it is today. It is possible for the hashing power of all inefficient (uses more power than would gain in rewards) mining machines (and hence not connected to the network) to outnumber the hashing power of all mining machines on the network. This requires low block rewards in real terms, expensive electricity costs in real terms and a relatively small difference in efficiency between the inefficient and the efficient mining machines. In this case an attacker could gain 51% hashing power very easily  to perform a double spend since unused miners are virtually worthless (satoshi didn't envision this).

We need much more discussion about the security assumptions of bitcoin. New technologies may allow us to gain more security/decentralisation in some areas but at a potential trade off with other areas.


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 06:19:47 PM
telepathetic,

 not to mention that there is a (unknown and likely linear) relationship between intrinsic value of BTC and cost and presence of hashing power.  Thus this means that, at best we need to have a certain amount of hash power present and running in order to support what Color Coins wants to support.  If this hash power fails to emerge, then you will have a huge catastrophe.

 another point- why do we need to run an ASIC for every bond issued in the universe when models such as NXT remove this requirement?  Then we can expand the economy indefinitely.

 it goes back to the gold bug mentality.  They insist that we must base our economy on gold because gold is valuable[1], however they ignore the fact that it is only valuable because we agree that it's valuable.  How valuable is gold to a chimpanzee?

-bm


[1] we must base a cryptocoin on hashing because hashing is hard


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 20, 2014, 06:32:45 PM
telepathetic,

 not to mention that there is a (unknown and likely linear) relationship between intrinsic value of BTC and cost and presence of hashing power. 

Somewhat.

There was high correlation until the price crashed after gox.  Now prices are half of what they were, yet hashing power has increased.


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 06:40:30 PM
telepathetic,

 not to mention that there is a (unknown and likely linear) relationship between intrinsic value of BTC and cost and presence of hashing power. 

Somewhat.

There was high correlation until the price crashed after gox.  Now prices are half of what they were, yet hashing power has increased.


that's because it was overpriced.

-bm


Title: Re: Decentralized Timestamp
Post by: Cryddit on May 20, 2014, 07:21:30 PM

Colored Coins etc. make it much harder to know how much value we need the blockchain to protect.  The fact that these values are essentially "hidden" from the protocol means we can't tell what we need to do to maintain any kind of parity with them.

One popular (and possibly correct) view of things is that in the long run the cheapest available price of electricity times the amount of electricity spent per block, will approach the value of the block reward in a PoW system. 

Right now we have a Bitcoin block reward worth approx. $12000.  If this view is correct, we should expect, worldwide, to see about $12000 worth of electricity (increasingly concentrated where electricity is cheapest) expended per block by hashing rigs. 

Right now transaction fees are providing a very small percentage (one third of one percent?  I think?) of the block rewards. 

At  some point in the future, moving to transaction fees as a primary source of mining revenue, implies that each kilowatt-hour of electricity invested in securing the blockchain will have to secure three hundred times as much value (relative to its own value) from attack as it does now. 

I'm convinced that's not really enough.  If we stick with Proof-of-work, we're going to have to start charging transaction fees based on how much value is changing hands, because we want to buy security proportional to the value we're trying to secure, not proportional to the amount of space it takes to store the transaction.  And that means the amount of value changing hands has to be visible, and that therefore Colored Coins etc will have to be more 'transparent' in terms of the protocol knowing how much they're worth (and therefore how much security we need to buy to keep them secure).



Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 08:01:19 PM

Colored Coins etc. make it much harder to know how much value we need the blockchain to protect.  The fact that these values are essentially "hidden" from the protocol means we can't tell what we need to do to maintain any kind of parity with them.

One popular (and possibly correct) view of things is that in the long run the cheapest available price of electricity times the amount of electricity spent per block, will approach the value of the block reward in a PoW system. 

that's perhaps the asymptotic value of a block reward in a PoW system- we will always have secondary costs although they will theoretically get lower as time goes by.  But really can we predict much of anything in that time frame?

Right now we have a Bitcoin block reward worth approx. $12000.  If this view is correct, we should expect, worldwide, to see about $12000 worth of electricity (increasingly concentrated where electricity is cheapest) expended per block by hashing rigs. 

Right now transaction fees are providing a very small percentage (one third of one percent?  I think?) of the block rewards. 

At  some point in the future, moving to transaction fees as a primary source of mining revenue, implies that each kilowatt-hour of electricity invested in securing the blockchain will have to secure three hundred times as much value (relative to its own value) from attack as it does now. 

I'm convinced that's not really enough.  If we stick with Proof-of-work, we're going to have to start charging transaction fees based on how much value is changing hands, because we want to buy security proportional to the value we're trying to secure, not proportional to the amount of space it takes to store the transaction.  And that means the amount of value changing hands has to be visible, and that therefore Colored Coins etc will have to be more 'transparent' in terms of the protocol knowing how much they're worth (and therefore how much security we need to buy to keep them secure).

the problem of transaction fees is even more serious and I've pointed this out before.

1) it's a given that TX fees will need to increase over time

2) if they increase past a certain threshold and the use of bitcoin becomes more expensive than alternatives like Paypal, not only will Bitcoin become unattractive for users, it will become unattractive for investors, and thus there will be a collapse in price.  I can't see how we can avoid this future as the computation requirements to run the bitcoin network get larger and larger.  Again, NXT does not have these issues.

-bm


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 20, 2014, 08:05:36 PM


1) it's a given that TX fees will need to increase over time
 


why is that a given?



Title: Re: Decentralized Timestamp
Post by: Cryddit on May 20, 2014, 08:26:40 PM
one problem with the ASIC race is that the force we're trying to secure the blockchain against is the same force that we're using to secure it.

It's hashing power on the attack and hashing power on the defense.  If the legit market calls hashing power into existence, then some future reversal or shift in circumstance can move that hashing power from defense to attack.  And with marginal profits from defense approaching zero, the miners are always balanced on this knife edge where the smallest change could make an atack more profitable than continuing defense.

I'm reminded of what Pratchett's character Vetinari said about hiring mercenaries:  You have to pay them to start fighting, and unless you are very lucky you also have to pay them to stop.


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 20, 2014, 08:32:00 PM
one problem with the ASIC race is that the force we're trying to secure the blockchain against is the same force that we're using to secure it.

It's hashing power on the attack and hashing power on the defense.  If the legit market calls hashing power into existence, then some future reversal or shift in circumstance can move that hashing power from defense to attack.  And with marginal profits from defense approaching zero, the miners are always balanced on this knife edge where the smallest change could make an atack more profitable than continuing defense.

I'm reminded of what Pratchett's character Vetinari said about hiring mercenaries:  You have to pay them to start fighting, and unless you are very lucky you also have to pay them to stop.

interesting.

I think what we might see in the future is some kind of normalization. 

The network hashrate growth will slow down, stop, or possibly decline at some point...
Mining will be seen less as opportunistic, and more in line with other businesses
that require years to reach breakeven.

So, profits may shrink, but things may become more stable and predictable.


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 20, 2014, 08:55:31 PM
What do you mean by iterating through thousands of possible current block signatures?

Signatures are dependent on the data they are signing and my public key, my public key is fixed but the data I am signing is not. I can add and remove transactions to the block to change the output of the signature. (Technically with ECDSA signatures you don't even need to do that, you just change the nonce used in signing to get a different signature)

There is no ECDSA involved. Just sha256.


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 20, 2014, 09:03:34 PM
Signatures are dependent on the data they are signing and my public key, my public key is fixed but the data I am signing is not. I can add and remove transactions to the block to change the output of the signature. (Technically with ECDSA signatures you don't even need to do that, you just change the nonce used in signing to get a different signature)

There is no ECDSA involved. Just sha256.

Yes there is, when you sign a block with NXT you sign it using ECDSA. It is this signature that is used to calculate who gets to sign the next block and therefore you need to iterate through different ECDSA possibilities to produce the lowest value when you combine it with your public key and take the SHA256 hash of the two combined.


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 09:06:14 PM


1) it's a given that TX fees will need to increase over time
 


why is that a given?


because block rewards will decrease.

from the Bitcoin wiki (https://en.bitcoin.it/wiki/Controlled_supply) : "The number of Bitcoins generated per block is set to decrease geometrically"

eventually the reward will be so small compared to the cost to generate them that TX fees will be required.  At that point we're not completely sure what will happen.  Tulips anyone?  :)

-bm


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 20, 2014, 09:06:36 PM
In a double spend attack (including a "51% attack) the attacker would be the one generating the sequence of blocks.  That means each block relies on the prior block also made by the attacker.  The attacker signs a block and if it doesn't allow him to forge the next block, just keeps resigning it until it does (as pointed out a single digest can have an infinite number of unique signatures by changing the k value). The attacker attempts signatures until he produces a one which allows him to sign the next block as well.  The attacker then moves on to the next block.  If this seems kind of like a PoW it is.

Let me correct this nonsense.

As no ECDSA is involved and the only thing that can be used in

generation_signature_hash = sha256(generation_signature_of_current_block + my_public_key) <<<<< + means concat

to manipulate are:

generation_signature_of_current_block  << fixed by the previous block
my_public_key                                  << fixed by the number of accounts an attacker has


So, the only thing he can do, is to create billions of accounts holding at least >0 NXT to try out each of them.


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 20, 2014, 09:07:56 PM
Signatures are dependent on the data they are signing and my public key, my public key is fixed but the data I am signing is not. I can add and remove transactions to the block to change the output of the signature. (Technically with ECDSA signatures you don't even need to do that, you just change the nonce used in signing to get a different signature)

There is no ECDSA involved. Just sha256.

Yes there is, when you sign a block with NXT you sign it using ECDSA. It is this signature that is used to calculate who gets to sign the next block and therefore you need to iterate through different ECDSA possibilities to produce the lowest value when you combine it with your public key and take the SHA256 hash of the two combined.

Show me the code.

This is what I mean:
 1) https://bitbucket.org/JeanLucPicard/nxt/src/046e59e4df43309a37c2789efd39dba4a873bbe2/src/java/nxt/Generator.java?at=master#cl-118
 2) https://bitbucket.org/JeanLucPicard/nxt/src/046e59e4df43309a37c2789efd39dba4a873bbe2/src/java/nxt/BlockchainProcessorImpl.java?at=master#cl-731

No ECDSA involved.


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 09:10:35 PM
one problem with the ASIC race is that the force we're trying to secure the blockchain against is the same force that we're using to secure it.

It's hashing power on the attack and hashing power on the defense.  If the legit market calls hashing power into existence, then some future reversal or shift in circumstance can move that hashing power from defense to attack.  And with marginal profits from defense approaching zero, the miners are always balanced on this knife edge where the smallest change could make an atack more profitable than continuing defense.

I'm reminded of what Pratchett's character Vetinari said about hiring mercenaries:  You have to pay them to start fighting, and unless you are very lucky you also have to pay them to stop.

it reminds me of the cold war US-Soviet Nuclear Détente (http://www.history.com/topics/cold-war/detente).

-bm


Title: Re: Decentralized Timestamp
Post by: jonald_fyookball on May 20, 2014, 09:12:17 PM


1) it's a given that TX fees will need to increase over time
 


why is that a given?


because block rewards will decrease.

from the Bitcoin wiki (https://en.bitcoin.it/wiki/Controlled_supply) : "The number of Bitcoins generated per block is set to decrease geometrically"

eventually the reward will be so small compared to the cost to generate them that TX fees will be required.  At that point we're not completely sure what will happen.  Tulips anyone?  :)

-bm

Yes but that "eventually" is a ways off.  
There's many more years of mining for block rewards.  
I don't think anyone is seriously worried about this
right now.  

Talk to me in 5 years about it.  :)



Title: Re: Decentralized Timestamp
Post by: Peter R on May 20, 2014, 09:13:55 PM
I've been bashing my head against the wall with Bluemeanie over here too: https://bitcointalk.org/index.php?topic=613643.msg6841920#msg6841920

1.  He does not believe that the cost to produce a commodity tends to the market price of that commodity.  For example, the cost to produce 25 BTC (in USD) tends to the market value of those 25 BTC, so as the market value of bitcoin increases so to does the cost of attempting a 3-confirm double-spend.  He apparently disagree and calls this "pulp fiction economics."  

2.  He does not understand that "attacking the network" to attempt to reverse a colored-coin trade for bitcoin is sort of pointless.  If Bluemeanie buys my colored coin for 100 BTC and then double-spends to reverse the transaction (after spending a lot of money to do so), sure he'll end up with his 100 BTC back in the unlikely case that he is successful, but I'll end up with my colored coin back.  With coinjoin, the trade was a single transaction.  

Point 2 is why digital IOUs like colored coins are most likely to trade on the dominant network (which is presently bitcoin).  You can't trade digital assets for real bitcoins in a trustless way on the Nxt network like you can using colored coins.  Ironically, I was discussing this point with Nxt advocates and they told me that I was wrong here too--that you can trade Nxt assets for real bitcoins in a trustless way.    





Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 20, 2014, 09:23:18 PM
Signatures are dependent on the data they are signing and my public key, my public key is fixed but the data I am signing is not. I can add and remove transactions to the block to change the output of the signature. (Technically with ECDSA signatures you don't even need to do that, you just change the nonce used in signing to get a different signature)

There is no ECDSA involved. Just sha256.

Yes there is, when you sign a block with NXT you sign it using ECDSA. It is this signature that is used to calculate who gets to sign the next block and therefore you need to iterate through different ECDSA possibilities to produce the lowest value when you combine it with your public key and take the SHA256 hash of the two combined.

Show me the code.

This is what I mean:
 1) https://bitbucket.org/JeanLucPicard/nxt/src/046e59e4df43309a37c2789efd39dba4a873bbe2/src/java/nxt/Generator.java?at=master#cl-118
 2) https://bitbucket.org/JeanLucPicard/nxt/src/046e59e4df43309a37c2789efd39dba4a873bbe2/src/java/nxt/BlockchainProcessorImpl.java?at=master#cl-731

No ECDSA involved.

I think I see now the cause for this confusion. Let me put it simply:

generation signature is not block signature

generation signature = hash(generation signature of previous block concatenated with the forger's public key)
block signature = signature of block; forger's private key required


purpose of generation signature => providing the hit
purpose of block signature => providing block integrity


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 09:28:08 PM
you're greatly misconstruing my points.

This is one VIEWPOINT on economics and it centers around the notion of scarcity.

-bm



Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 09:30:39 PM

2.  He does not understand that "attacking the network" to attempt to reverse a colored-coin trade for bitcoin is sort of pointless.  If Bluemeanie buys my colored coin for 100 BTC and then double-spends to reverse the transaction (after spending a lot of money to do so), sure he'll end up with his 100 BTC back in the unlikely case that he is successful, but I'll end up with my colored coin back.  With coinjoin, the trade was a single transaction.  


you clearly dont understand the nature of these risks and I suggest you do more reading here and less posting.

THANKS!   ;D

-bm


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 20, 2014, 09:52:10 PM
I think I see now the cause for this confusion. Let me put it simply:

generation signature is not block signature

generation signature = hash(generation signature of previous block concatenated with the forger's public key)
block signature = signature of block; forger's private key required


purpose of generation signature => providing the hit
purpose of block signature => providing block integrity

You still aren't understanding me. You have to get lucky and be allocated a block randomly as per normal. Now you get the chance to create a block signature. Once you get this opportunity you can iterate through many different possibilities for the block signature such that the next block is guaranteed to be signed by you.

The crucial bit of the code is hash(generation signature of previous block concatenated with the forger's public key). If you are able to manipulate the signature of the previous block because you were randomly allocated the ability to sign the previous block then you can make sure this hash is very small.


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 20, 2014, 09:55:30 PM
2.  He does not understand that "attacking the network" to attempt to reverse a colored-coin trade for bitcoin is sort of pointless.  If Bluemeanie buys my colored coin for 100 BTC and then double-spends to reverse the transaction (after spending a lot of money to do so), sure he'll end up with his 100 BTC back in the unlikely case that he is successful, but I'll end up with my colored coin back.  With coinjoin, the trade was a single transaction.    

Some people don't use these special transactions and instead exchange coloured coins/ mastercoins directly for fiat or products or services, this enables successful double spends.


Title: Re: Decentralized Timestamp
Post by: Peter R on May 20, 2014, 10:06:32 PM
2.  He does not understand that "attacking the network" to attempt to reverse a colored-coin trade for bitcoin is sort of pointless.  If Bluemeanie buys my colored coin for 100 BTC and then double-spends to reverse the transaction (after spending a lot of money to do so), sure he'll end up with his 100 BTC back in the unlikely case that he is successful, but I'll end up with my colored coin back.  With coinjoin, the trade was a single transaction.    

Some people don't use these special transactions and instead exchange coloured coins/ mastercoins directly for fiat or products or services, this enables successful double spends.

Correct.  Double spends are possible when trading blockchain assets for something external to the blockchain, whether the blockchain assets are bitcoins or colored coins.  The advantage of colored coins on the bitcoin network is they can be traded risk-free for bitcoins (since they are registered on the same blockchain and can be exchanged with a single coinjoin TX). 

In other words, there is an advantage to trading assets registered on a particular blockchain with the native currency of that blockchain because these trades can be made risk free (the trade either happens or it doesn't--one party can't get stiffed).   


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 10:30:30 PM
2.  He does not understand that "attacking the network" to attempt to reverse a colored-coin trade for bitcoin is sort of pointless.  If Bluemeanie buys my colored coin for 100 BTC and then double-spends to reverse the transaction (after spending a lot of money to do so), sure he'll end up with his 100 BTC back in the unlikely case that he is successful, but I'll end up with my colored coin back.  With coinjoin, the trade was a single transaction.    

Some people don't use these special transactions and instead exchange coloured coins/ mastercoins directly for fiat or products or services, this enables successful double spends.


these assets are presumably exchangeable for something else outside the system.  Let's say I can exchange the cryptonote for gold at any time.  So I exchange it for gold, then release my counterfeit chain where I still own the gold note.  Then cash it in for gold again?

if such an event were to occur the entire system would collapse because confidence would be destroyed.

it's not difficult to execute such an attack.

-bm


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 20, 2014, 10:31:52 PM
2.  He does not understand that "attacking the network" to attempt to reverse a colored-coin trade for bitcoin is sort of pointless.  If Bluemeanie buys my colored coin for 100 BTC and then double-spends to reverse the transaction (after spending a lot of money to do so), sure he'll end up with his 100 BTC back in the unlikely case that he is successful, but I'll end up with my colored coin back.  With coinjoin, the trade was a single transaction.    

Some people don't use these special transactions and instead exchange coloured coins/ mastercoins directly for fiat or products or services, this enables successful double spends.

Correct.  Double spends are possible when trading blockchain assets for something external to the blockchain, whether the blockchain assets are bitcoins or colored coins.  The advantage of colored coins on the bitcoin network is they can be traded risk-free for bitcoins (since they are registered on the same blockchain and can be exchanged with a single coinjoin TX). 

In other words, there is an advantage to trading assets registered on a particular blockchain with the native currency of that blockchain because these trades can be made risk free (the trade either happens or it doesn't--one party can't get stiffed).   


even if you want to believe this scenario still somehow preserves the value of Color Coins technology you ignore the fact that you can reverse price collapses and market rallies.

-bm


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 21, 2014, 06:47:26 AM
You still aren't understanding me. You have to get lucky and be allocated a block randomly as per normal. Now you get the chance to create a block signature. Once you get this opportunity you can iterate through many different possibilities for the block signature such that the next block is guaranteed to be signed by you.

The crucial bit of the code is hash(generation signature of previous block concatenated with the forger's public key). If you are able to manipulate the signature of the previous block because you were randomly allocated the ability to sign the previous block then you can make sure this hash is very small.

Why do you still referring to the block signature? It has nothing to do with forging.

You cannot iterate through many different possibilities for the generation signature because there is only one possibility for each account.


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 21, 2014, 08:04:47 AM

Why do you still referring to the block signature? It has nothing to do with forging.

You cannot iterate through many different possibilities for the generation signature because there is only one possibility for each account.

I've looked through the code again and I am wrong. The generator signature is completely deterministic and  not a signature just a hash. This allows a forger to look ahead and see likely next values of the generator signature/hash and so simply transfer coins to a public key calculated such that it has a high probability of being a future forger.


Title: Re: Decentralized Timestamp
Post by: gmaxwell on May 21, 2014, 08:09:04 AM
The generator signature is completely deterministic and  not a signature just a hash.
It was a signature in their original code. Whats is it a hash over now?


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 21, 2014, 08:31:28 AM
It was a signature in their original code. Whats is it a hash over now?

It is the SHA256 hash of the previous generation signature concatenated with the block signers public key.


Title: Re: Decentralized Timestamp
Post by: shekelsteingoyberg2 on May 21, 2014, 09:07:01 AM
So I was discussing this with a friend was wondering if you guys had any input, how would you go about creating a decentralized system that agrees on the current time?

Preferably not Proof of Work.

Thanks.

https://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf

Re-invent the wheel for your special protocol?


Title: Re: Decentralized Timestamp
Post by: iruu on May 21, 2014, 09:12:53 AM
This leads to fun outcomes like old stake holders can exit the system (sell their coins) and then sell their old keys to people go fork off the chain at a point in the past, at no cost to themselves. Someone who is later handed two histories— the real one and the simulated one— cannot distinguish them, they can tell— perhaps— that someone was naughty, but that doesn't help them decide which chain is the good one.
That's not true, as in that's not a characteristic of PoS. It's a characteristic of flawed PoS.  

A transaction in block x has to be equivalent to signing it by stake held in inputs (or accounts, whatever the design of the system is).  
Transactions have to be valid in only one blockchain, as to not be replayed.  
If A has 30% of stake, the fake empty block created by A has the same validity as a block generated by A with A's selling transaction to someone. Now the buyer and A can both create their equivalent blockchains. However, all it takes to make one blockchain one valid is another stake signing one block in one of the blockchains in the future.

Fake block stake validity, all by A:
30%, 30%, 30%

True blockchain stake signed:
30% (A's stake, selling), 30% (buyer), 30% (buyer) + 1% (someone else, B)

By signing third block, B effectively validates all blocks before him. So now first fake block has 30% of stake behind it, and true block (with selling transaction) 31%.  

Quote
There are a number of other related implications.  A number of different modifications have been proposed, but so far all of them seem to be obfuscation and not actually fix the underlying issue, which seems a bit fundamental.

You can read more about this in Section 5 of https://download.wpsoftware.net/bitcoin/asic-faq.pdf

It's trivial to create a rule which makes one block with identical stake better than another, like a comparison of hashes. This would lead the honest nodes to completely ignore the worse block. To break that would be equivalent to acting directly against self financial interest, for no reason, and as long as all people in control of a currency don't act against their interests, everything works.  
It's no different to PoW. If I own serious money in a specific cryptocurrency, I'm not going to endanger that, because that would be very costly, although indirectly, just as mining forks in PoW is costly.

Most people living in skyscrapers don't steal and destroy bricks from foundation.  

Note that it takes just one person with one coin to behave correctly, even if literally everyone else is signing all forks, and everything works.  

Why for no reason? Because this shouldn't be profitable, if it is, it's a design error. I don't think it's that important though.  


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 21, 2014, 09:15:49 AM
The generator signature is completely deterministic and  not a signature just a hash.
It was a signature in their original code. Whats is it a hash over now?

That was a trap for clones.


Title: Re: Decentralized Timestamp
Post by: shekelsteingoyberg2 on May 21, 2014, 09:21:24 AM
So I was discussing this with a friend was wondering if you guys had any input, how would you go about creating a decentralized system that agrees on the current time?

Preferably not Proof of Work.

Thanks.

https://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf

Re-invent the wheel for your special protocol?


Hate to quote myself, but Lamport is able to establish a meaningful logical clock by the participants of the system interacting, I suppose this might be considered PoW, but does it have to be someone mining?  Would the time network fall apart if only one or two systems were a part of the network at some point in the future?


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 21, 2014, 09:25:15 AM
So I was discussing this with a friend was wondering if you guys had any input, how would you go about creating a decentralized system that agrees on the current time?

Preferably not Proof of Work.

Thanks.

https://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf

Re-invent the wheel for your special protocol?


Hate to quote myself, but Lamport is able to establish a meaningful logical clock by the participants of the system interacting, I suppose this might be considered PoW, but does it have to be someone mining?  Would the time network fall apart if only one or two systems were a part of the network at some point in the future?

It only works if everyone in the system is honest. If you use the assumption that everyone is honest, you might as well just randomly pick a single node to tell everyone else what the time is.


Title: Re: Decentralized Timestamp
Post by: shekelsteingoyberg2 on May 21, 2014, 09:30:22 AM
It is virtually impossible due to Sybil attacks. Bitcoin is as close to a decentralised timestamp system as you will get.

nope, can be done.  I have a working model.  see:  http://www.stanford.edu/class/cs240/readings/lamport.pdf

if you review that paper maybe we can discuss how to do this, otherwise I'll save it for later.

later friends!  -bm


Oh someone beat me to it.
Oh well, it's a popular paper I suppose.


Title: Re: Decentralized Timestamp
Post by: jtimon on May 21, 2014, 10:42:05 AM
not to mention that there is a (unknown and likely linear) relationship between intrinsic value of BTC and cost and presence of hashing power. 

First of all, there's no such thing as "intrinsic value". It is outrageous that you hold this medieval dogma and at the same time pretend to lecture others on the social science of economics.

Let's cite Carl Menger first:

"[v]alue is… nothing inherent in goods, no property of them, but merely the importance that we first attribute to the satisfaction of our needs... and in consequence carry over to economic goods as the… causes of the satisfaction of our needs." (Principles of Economics)

I really prefer Silvio Gesell's critique, and I find this part specially comical:

https://www.community-exchange.org/docs/Gesell/en/neo/part3/3.htm
"The presence of value can be demonstrated on the weighing-machine: "fully-valued". Whether there are any other processes for detecting value has not yet been established. Litmus paper seems to be insensitive to value, the magnetic needle is not deflected by it; it withstands the highest known temperatures. Indeed our whole knowledge of value is still somewhat meagre, we only know that it exists. This is unfortunate, considering the "fundamental importance" of value in science and in life. New possibilities are, however, opened up by Dr. Helfferich's discovery that with some "substances containing value" (Wertstoffe) the value is not always proportionate to the Substance. The substance containing the value is greater or smaller than the value of the substance. He has discovered that the value of silver money is twice the value of the silver used in its manufacture. Silver money thus contains value in double concentration, and we have therefore an extract of value. This important discovery gives a quite new insight into the nature of value. It shows that value can be extracted, concentrated and, as it were, separated from its substance. We may therefore hope that science will at some future date be able to produce chemically pure value. But here again we have a contradiction. In a roundabout way we have reached the theory of a paper-money standard. But this theory is based solely on price and leaves the theory of value severely alone."

Hehe, it seems to me that some people in the cryptocurrency space are precisely trying to produce "cryptographically pure value"...

Anyway, as Peter R explains (https://bitcointalk.org/index.php?topic=613643.msg6841920#msg6841920) the relationship between the price of BTC and mining investment is very simple: while the costs of mining are lower than the mining reward (which is a function of the price of BTC), more investment in mining equipment is to be expected.
This is not "pulp fiction economics" but simple supply and demand.

From wikipedia (http://en.wikipedia.org/wiki/Supply_and_demand):

"If demand increases (demand curve shifts to the right) and supply remains unchanged, a shortage occurs, leading to a higher equilibrium price."

So when miner's cost are lower than the reward price, they get a profit. Profits encourage competition, we know that (also from wikipedia (http://en.wikipedia.org/wiki/Economic_profit#In_competitive_and_contestable_markets)): "Economic profit does not occur in perfect competition in long run equilibrium". So the explanation of the relationship between BTC price and hashing power is really simple: when prices rise the market produces more hashing power trying to reach an equilibrium.
It has nothing to do with "a law of bitcoin value", with the "intrinsic value" myth or with the phantom that is value.

Just another funny joke from Gesell criticizing Marx, hehehe:

"Marx, whose economic system is founded upon a theory of value, uses almost the same words: "Value is a phantom" - which does not, however, prevent him from attempting to conjure up this phantom in three bulky volumes."


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 21, 2014, 11:57:03 AM

Why do you still referring to the block signature? It has nothing to do with forging.

You cannot iterate through many different possibilities for the generation signature because there is only one possibility for each account.

I've looked through the code again and I am wrong. The generator signature is completely deterministic and  not a signature just a hash. This allows a forger to look ahead and see likely next values of the generator signature/hash and so simply transfer coins to a public key calculated such that it has a high probability of being a future forger.


Well, it is not that easy, though. You need to wait at least 1441 blocks for a new account being able to forge.

During this period, real-world randomness could easily destroy the ability to forge of your carefully crafted account.

Furthermore, we are going to introduce more entropy in order to predict the next say 20 forgers (which is required to have a high transaction rate) but after that it is completely random.


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 21, 2014, 12:51:23 PM
Well, it is not that easy, though. You need to wait at least 1441 blocks for a new account being able to forge.

During this period, real-world randomness could easily destroy the ability to forge of your carefully crafted account.

Furthermore, we are going to introduce more entropy in order to predict the next say 20 forgers (which is required to have a high transaction rate) but after that it is completely random.

I wondered about that. 1440 is too many blocks to correctly guess unless everyone does forge when they are allowed to.


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 21, 2014, 02:11:45 PM
Well, it is not that easy, though. You need to wait at least 1441 blocks for a new account being able to forge.

During this period, real-world randomness could easily destroy the ability to forge of your carefully crafted account.

Furthermore, we are going to introduce more entropy in order to predict the next say 20 forgers (which is required to have a high transaction rate) but after that it is completely random.

I wondered about that. 1440 is too many blocks to correctly guess unless everyone does forge when they are allowed to.

Exactly. Even balances could change dramatically to change the forging queue of future blocks.

In any case, we would like to increase the uncertainty to 100% after n blocks where n << 1440.

We have approaches reaching from forking the network deliberately to using reverse hashchains to include random numbers into blocks. These random numbers get included into the generation signature and make the forger prediction impossible after n blocks.


Title: Re: Decentralized Timestamp
Post by: telepatheic on May 21, 2014, 03:23:52 PM
In any case, we would like to increase the uncertainty to 100% after n blocks where n << 1440.

We have approaches reaching from forking the network deliberately to using reverse hashchains to include random numbers into blocks. These random numbers get included into the generation signature and make the forger prediction impossible at a particular block height.

This is essentially copying peercoin's StakeModifier

If I sign a block at height n either the person who gets to sign the block (with first preference) at height n+m is known to me or unknown. If the person is known then there is nothing I can do to affect this. If the person is unknown but at height n+1 the person who gets to sign the block at n+m is known, that implies that something in block n decided who got to sign the block n+m. Since I have complete control over what is included in block n, I get to decide.

This applies to NXT and to peercoin. With NXT, the previous signer gets to choose who gets to sign the next one. However they only have 1 bit of control. They can either choose someone (signing the block) or choose not to sign the block and delegate the choice to the second preference signer who gets to choose someone (signing the block) or choose not to sign the block and delegate the choice to the third preference signer...


Title: Re: Decentralized Timestamp
Post by: ChuckOne on May 21, 2014, 03:47:44 PM
In any case, we would like to increase the uncertainty to 100% after n blocks where n << 1440.

We have approaches reaching from forking the network deliberately to using reverse hashchains to include random numbers into blocks. These random numbers get included into the generation signature and make the forger prediction impossible at a particular block height.

This is essentially copying peercoin's StakeModifier

If I sign a block at height n either the person who gets to sign the block (with first preference) at height n+m is known to me or unknown. If the person is known then there is nothing I can do to affect this. If the person is unknown but at height n+1 the person who gets to sign the block at n+m is known, that implies that something in block n decided who got to sign the block n+m. Since I have complete control over what is included in block n, I get to decide.

This applies to NXT and to peercoin. With NXT, the previous signer gets to choose who gets to sign the next one. However they only have 1 bit of control. They can either choose someone (signing the block) or choose not to sign the block and delegate the choice to the second preference signer who gets to choose someone (signing the block) or choose not to sign the block and delegate the choice to the third preference signer...

I told you, we use reverse hashchains. So, you as a forger are forced to publish a previously publicly unknown number. However, everybody can check if you published the correct number. So, there is no choosing in what you include in your block.

And, btw. who says that everybody should include random numbers into their blocks? ;)


Title: Re: Decentralized Timestamp
Post by: bluemeanie1 on May 21, 2014, 06:18:17 PM
So I was discussing this with a friend was wondering if you guys had any input, how would you go about creating a decentralized system that agrees on the current time?

Preferably not Proof of Work.

Thanks.

https://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf

Re-invent the wheel for your special protocol?


Hate to quote myself, but Lamport is able to establish a meaningful logical clock by the participants of the system interacting, I suppose this might be considered PoW, but does it have to be someone mining?  Would the time network fall apart if only one or two systems were a part of the network at some point in the future?

It only works if everyone in the system is honest. If you use the assumption that everyone is honest, you might as well just randomly pick a single node to tell everyone else what the time is.

it's fully considered in my concept.

-bm


Title: Re: Decentralized Timestamp
Post by: zawy on October 20, 2017, 10:23:40 AM
how would you go about creating a decentralized system that agrees on the current time?

Preferably not Proof of Work.

Quote
Preferably not Proof of Work.
Your question stops being interesting when you start removing the only known solution for strong decentralized consensus— even in the proof of work model an effort to do consensus time probably fails for incentive reasons, but no one knows how to do decenteralized consensus absent the expenditure of work.

I have a solution gmaxwell hasn't thought of. By looking at the stars with a camera to periodically calibrate, time can be an objective fact computers can determine for themselves without consensus.  Honest nodes would reject dishonest transactions and blocks that do not have the correct time, within some error.  With this solution, mining and blocks are not needed.  It would be a simpler "transaction chain".  Nodes would share transactions and reject spends of the same coin if they occur within say 1 minute of each other, or reject any second spend that occurred more than 1 minute after the 1st one.