Topic: [ANN][CLAM] CLAMs, Proof-Of-Chain, Proof-Of-Working-Stake, a.k.a. "Clamcoin" - page 192. (Read 1151369 times)
December 26, 2015, 01:42:42 PM
Something I can not quite understand why my antivirus activity is perceived as a purse suspicious activity. Other purses on my PC work
December 26, 2015, 11:40:43 AM
After thinking some more, I think it would be a mistake for the parties to such contracts to register an identity. There's no reason for the party/seller/Alice or the counterparty/buyer/Bob to reuse addresses since they don't need to have a persistent identity across trades. For privacy reasons, it's probably best to discourage address reuse for the party and counterparty. The escrow, on the other hand, will have policies across many contracts and future parties will want to audit and make sure the escrow agent has never misbehaved.
It probably makes sense for escrow agents to register an identity along with information about the terms under which they provide escrow. This will correspond to a fixed pubkey.
The "contract tx" would store the contract information and the chosen escrow agent (identified by the registered id) in the clamSpeech slot. The party and counterparty could be derived from the first and second inputs of the tx.
But obviously I'm still thinking this through, so I'm open to suggestion.
Thanks for the positive feedback!
It probably makes sense for escrow agents to register an identity along with information about the terms under which they provide escrow. This will correspond to a fixed pubkey.
The "contract tx" would store the contract information and the chosen escrow agent (identified by the registered id) in the clamSpeech slot. The party and counterparty could be derived from the first and second inputs of the tx.
But obviously I'm still thinking this through, so I'm open to suggestion.
Nice project ithink it should be possible, and implement it to clams would be a nice add which should get up a little more the price
Thanks for the positive feedback!
December 26, 2015, 10:35:12 AM
Earlier this year I wrote up an idea I called "multisig derivatives" that could be used to hedge against volatility. (I guess that would've been useful during Clampocalypse.) I've been thinking about it again, and now know how to present the idea in what I hope is a simpler way. It's basically a way of simulating buying and selling cryptocurrencies relative to other assets (e.g., fiat currencies). I wrote up a short explanation yesterday, using bitcoins and dollars:
https://medium.com/@trentrussell/contracts-simulating-crypto-fiat-exchanges-6f9421ea520c
I plan to implement this to work over clams, using clamSpeech to record the details of the contract.
One of the issues I'm not sure how to handle is identifying the parties. It's all intended to be pseudonymous and so the party is really identified by their pubkey. However, writing the full pubkey for 3 parties into each clamSpeech with a contract wastes space.
A way to deal with this would be for people to register "identities" (presumably short handles or pseudonyms, up to 14 characters long) associated with a pubkey. Then the contracts could reference the "identities" and look up the corresponding pubkey.
Here's how this could be done on-chain:
Suppose Alice wants to register the handle "Alice" and associate it with the pubkey Q which has address A. Assuming there's not an "Alice" already register, she could make a tx which spends with a first input from A and clamspeech "registerid:Alice" -- the pubkey Q would be visible since the first input spends from A, and its clear that the holder of the private key for Q signed the tx. This registration could be stored in a database (independent of Clams). Then in contracts when "Alice" is used, Q could be looked up.
It would probably also be important to allow Alice to change her pubkey registration. Changing from Q (A) to Q' (A') could be done by spending from A (input 1) and A' (input 2) in a tx with clamspeech "changepubkey".
Some of these identities could advertise themselves as escrow agents by registering certain terms under which they will act as an escrow agent.
Before going into any more details, I'm curious if anyone has comments. Are there objections to this? Or a clearer way to do this?
There is another possibility I've considered. Instead of storing the "identities" explicitly in the clamSpeech with the contract, the "identities" could be determined for each "contract tx" by looking at the inputs: (1) for party, (2) for counterparty and (3) for escrow.
I can see arguments for doing it either way. Thoughts?
https://medium.com/@trentrussell/contracts-simulating-crypto-fiat-exchanges-6f9421ea520c
I plan to implement this to work over clams, using clamSpeech to record the details of the contract.
One of the issues I'm not sure how to handle is identifying the parties. It's all intended to be pseudonymous and so the party is really identified by their pubkey. However, writing the full pubkey for 3 parties into each clamSpeech with a contract wastes space.
A way to deal with this would be for people to register "identities" (presumably short handles or pseudonyms, up to 14 characters long) associated with a pubkey. Then the contracts could reference the "identities" and look up the corresponding pubkey.
Here's how this could be done on-chain:
Suppose Alice wants to register the handle "Alice" and associate it with the pubkey Q which has address A. Assuming there's not an "Alice" already register, she could make a tx which spends with a first input from A and clamspeech "registerid:Alice" -- the pubkey Q would be visible since the first input spends from A, and its clear that the holder of the private key for Q signed the tx. This registration could be stored in a database (independent of Clams). Then in contracts when "Alice" is used, Q could be looked up.
It would probably also be important to allow Alice to change her pubkey registration. Changing from Q (A) to Q' (A') could be done by spending from A (input 1) and A' (input 2) in a tx with clamspeech "changepubkey".
Some of these identities could advertise themselves as escrow agents by registering certain terms under which they will act as an escrow agent.
Before going into any more details, I'm curious if anyone has comments. Are there objections to this? Or a clearer way to do this?
There is another possibility I've considered. Instead of storing the "identities" explicitly in the clamSpeech with the contract, the "identities" could be determined for each "contract tx" by looking at the inputs: (1) for party, (2) for counterparty and (3) for escrow.
I can see arguments for doing it either way. Thoughts?
Nice project ithink it should be possible, and implement it to clams would be a nice add which should get up a little more the price
December 26, 2015, 09:14:39 AM
Earlier this year I wrote up an idea I called "multisig derivatives" that could be used to hedge against volatility. (I guess that would've been useful during Clampocalypse.) I've been thinking about it again, and now know how to present the idea in what I hope is a simpler way. It's basically a way of simulating buying and selling cryptocurrencies relative to other assets (e.g., fiat currencies). I wrote up a short explanation yesterday, using bitcoins and dollars:
https://medium.com/@trentrussell/contracts-simulating-crypto-fiat-exchanges-6f9421ea520c
I plan to implement this to work over clams, using clamSpeech to record the details of the contract.
One of the issues I'm not sure how to handle is identifying the parties. It's all intended to be pseudonymous and so the party is really identified by their pubkey. However, writing the full pubkey for 3 parties into each clamSpeech with a contract wastes space.
A way to deal with this would be for people to register "identities" (presumably short handles or pseudonyms, up to 14 characters long) associated with a pubkey. Then the contracts could reference the "identities" and look up the corresponding pubkey.
Here's how this could be done on-chain:
Suppose Alice wants to register the handle "Alice" and associate it with the pubkey Q which has address A. Assuming there's not an "Alice" already register, she could make a tx which spends with a first input from A and clamspeech "registerid:Alice" -- the pubkey Q would be visible since the first input spends from A, and its clear that the holder of the private key for Q signed the tx. This registration could be stored in a database (independent of Clams). Then in contracts when "Alice" is used, Q could be looked up.
It would probably also be important to allow Alice to change her pubkey registration. Changing from Q (A) to Q' (A') could be done by spending from A (input 1) and A' (input 2) in a tx with clamspeech "changepubkey".
Some of these identities could advertise themselves as escrow agents by registering certain terms under which they will act as an escrow agent.
Before going into any more details, I'm curious if anyone has comments. Are there objections to this? Or a clearer way to do this?
There is another possibility I've considered. Instead of storing the "identities" explicitly in the clamSpeech with the contract, the "identities" could be determined for each "contract tx" by looking at the inputs: (1) for party, (2) for counterparty and (3) for escrow.
I can see arguments for doing it either way. Thoughts?
https://medium.com/@trentrussell/contracts-simulating-crypto-fiat-exchanges-6f9421ea520c
I plan to implement this to work over clams, using clamSpeech to record the details of the contract.
One of the issues I'm not sure how to handle is identifying the parties. It's all intended to be pseudonymous and so the party is really identified by their pubkey. However, writing the full pubkey for 3 parties into each clamSpeech with a contract wastes space.
A way to deal with this would be for people to register "identities" (presumably short handles or pseudonyms, up to 14 characters long) associated with a pubkey. Then the contracts could reference the "identities" and look up the corresponding pubkey.
Here's how this could be done on-chain:
Suppose Alice wants to register the handle "Alice" and associate it with the pubkey Q which has address A. Assuming there's not an "Alice" already register, she could make a tx which spends with a first input from A and clamspeech "registerid:Alice" -- the pubkey Q would be visible since the first input spends from A, and its clear that the holder of the private key for Q signed the tx. This registration could be stored in a database (independent of Clams). Then in contracts when "Alice" is used, Q could be looked up.
It would probably also be important to allow Alice to change her pubkey registration. Changing from Q (A) to Q' (A') could be done by spending from A (input 1) and A' (input 2) in a tx with clamspeech "changepubkey".
Some of these identities could advertise themselves as escrow agents by registering certain terms under which they will act as an escrow agent.
Before going into any more details, I'm curious if anyone has comments. Are there objections to this? Or a clearer way to do this?
There is another possibility I've considered. Instead of storing the "identities" explicitly in the clamSpeech with the contract, the "identities" could be determined for each "contract tx" by looking at the inputs: (1) for party, (2) for counterparty and (3) for escrow.
I can see arguments for doing it either way. Thoughts?
December 25, 2015, 11:41:51 PM
Isn't embeddedness usually referred to as an external force causing inefficiency and false signals?
I hadn't encountered 'Embeddedness' since leaving school; I will need to brush up a bit before I feel comfortable responding.
I hadn't encountered 'Embeddedness' since leaving school; I will need to brush up a bit before I feel comfortable responding.
Not as I understand the general meaning, no. I'll idly paste a chunk of wikipedia instead of actually crafting a response (it is Christmas) ..
Quote
Mark Granovetter[edit]
Economic Sociologist Mark Granovetter provided a new research paradigm (neo-substantivism) for these researchers. Granovetter argued that the neoclassical view of economic action which separated economics from society and culture promoted an 'undersocialized account' that atomises human behavior. Similarly, he argued, substantivists had an "over-socialized" view of economic actors, refusing to see the ways that rational choice could influence the ways they acted in traditional, "embedded" social roles.
Actors do not behave or decide as atoms outside a social context, nor do they adhere slavishly to a script written for them by the particular intersection of social categories that they happen to occupy. Their attempts at purposive action are instead embedded in concrete, ongoing systems of social relations. (Granovette 1985:487)[2]
Granovetter applied the concept of embeddedness to market societies, demonstrating that even there, "rational" economic exchanges are influenced by pre-existing social ties.[2] In his study of ethnic Chinese business networks in Indonesia, Granovetter found individuals' economic agency embedded in networks of strong personal relations. In processes of clientelization the cultivation of personal relationships between traders and customers assumes an equal or higher importance than the economic transactions involved. Economic exchanges are not carried out between strangers but rather by individuals involved in long-term continuing relationships.
Economic Sociologist Mark Granovetter provided a new research paradigm (neo-substantivism) for these researchers. Granovetter argued that the neoclassical view of economic action which separated economics from society and culture promoted an 'undersocialized account' that atomises human behavior. Similarly, he argued, substantivists had an "over-socialized" view of economic actors, refusing to see the ways that rational choice could influence the ways they acted in traditional, "embedded" social roles.
Actors do not behave or decide as atoms outside a social context, nor do they adhere slavishly to a script written for them by the particular intersection of social categories that they happen to occupy. Their attempts at purposive action are instead embedded in concrete, ongoing systems of social relations. (Granovette 1985:487)[2]
Granovetter applied the concept of embeddedness to market societies, demonstrating that even there, "rational" economic exchanges are influenced by pre-existing social ties.[2] In his study of ethnic Chinese business networks in Indonesia, Granovetter found individuals' economic agency embedded in networks of strong personal relations. In processes of clientelization the cultivation of personal relationships between traders and customers assumes an equal or higher importance than the economic transactions involved. Economic exchanges are not carried out between strangers but rather by individuals involved in long-term continuing relationships.
(My emphasis --- and the reason for my interest in the phenomenon)
Cheers
Graham
December 25, 2015, 08:08:49 PM
The data is essentially an expression of users' perceptions, perhaps even users' perceptions of others' perceptions.
The threat of perceptual distortions introduced by pluralistic ignorance is an important issue to consider, especially given the inexpressiveness of the value transfer protocol. There is no mechanism to transfer value other than that which can be described with cryptography, specifically it is incapable of transmitting the societal values that are normally mediated by all the stuff that comes with embeddedness.
The threat of perceptual distortions introduced by pluralistic ignorance is an important issue to consider, especially given the inexpressiveness of the value transfer protocol. There is no mechanism to transfer value other than that which can be described with cryptography, specifically it is incapable of transmitting the societal values that are normally mediated by all the stuff that comes with embeddedness.
A fair point.
Though, I would think that the pseudo-anonymous nature of the network would blunt social effects such as 'pluralistic ignorance'.
It is quite possible I am conceptualizing it incorrectly, however.
The good news is, of course, that CLAMour has no innate effect on the network.
Data is agnostic (though actions taken pursuant may not be).
Isn't embeddedness usually referred to as an external force causing inefficiency and false signals?
I hadn't encountered 'Embeddedness' since leaving school; I will need to brush up a bit before I feel comfortable responding.
No it isn't voting, but it is opinion polling and that's not exactly an under-developed field.
I have read talk in the past about a multi-triggered-fork bit-field in BTC (as opposed to version reporting, etc.).
And yet, I am not aware of another network that implements a provable means to gather this data.
This is particularly so for Proof-Of-Stake; to which the data is likely more useful.
Exactly how useful it is, of course, remains to be seen.
This is a social thing in essence and so all you're ever going to have to work with are warm fuzzies (aka “statistics”).
True.
Yet... warm fuzzies are almost always preferable to blind stumbling, no?
Cheers and Season's Greetings
To you as well
December 25, 2015, 03:25:49 PM
I suggest building from the 'master' branch in the nochowderforyou repository if you can, and want to use testnet. Other than that I guess the answer is "no, there's no testnet available yet, but there will be in the next release".
No problem. Thanks for the quick replies on a holiday. I might try to compile from the master branch in a day or two.
December 25, 2015, 02:59:19 PM
v1.4.17 -- I didn't recompile it. I just used the binary. I don't remember if it's 32 bit or 64 bit; let me know if you need me to find out. (It seems to be 32 bit based on "history | grep wget." I did a wget of the 64 bit version and then a bit later the 32 bit version. This is very likely to mean I tried the 64 bit version and it didn't work, so I fell back on the 32 bit version which did.) I could try to recompile if you think that might help. The mainnet version is working fine, though.
It's fine that you bring up that it should be running in the background, but that's not what's happening. The first time I just noticed "getinfo" still didn't work after half an hour. After that I started doing "ps aux | grep clam" to check if it's running. That's how I know it dies after a second or so.
It's fine that you bring up that it should be running in the background, but that's not what's happening. The first time I just noticed "getinfo" still didn't work after half an hour. After that I started doing "ps aux | grep clam" to check if it's running. That's how I know it dies after a second or so.
It seems that no released version works with testnet, for at least these reasons:
1) the checkpoint list is empty, causing the crash you saw
2) the testnet genesis block hash is wrong, meaning it won't accept any blocks from peers
I tried making changes to v1.4.17 to get testnet working, but it needs more still.
I suggest building from the 'master' branch in the nochowderforyou repository if you can, and want to use testnet. Other than that I guess the answer is "no, there's no testnet available yet, but there will be in the next release".
December 25, 2015, 02:31:12 PM
Thanks. This does seem to make it connect, but my cct dies after about a second. I'll include the contents of my testnet/clam.conf and the output in testnet/debug.log in case it helps. I am working on something I'll want to test soon, but it wouldn't be terrible to test it at first on the mainnet.
Can you tell me which version of the client you are using? Then I'll try using the same version and see if it dies for me too.
Also, you know the "daemon=1" line makes the process detach from the terminal but keep running in the background, right? It can look like it 'died' because you get your shell prompt back, but it's still running if you check the process list. I doubt that's what is going on in this case, but thought I'd mention it just in case.
v1.4.17 -- I didn't recompile it. I just used the binary.
It's fine that you bring up that it should be running in the background, but that's not what's happening. The first time I just noticed "getinfo" still didn't work after half an hour. After that I started doing "ps aux | grep clam" to check if it's running. That's how I know it dies after a second or so.
December 25, 2015, 01:52:57 PM
Thanks. This does seem to make it connect, but my cct dies after about a second. I'll include the contents of my testnet/clam.conf and the output in testnet/debug.log in case it helps. I am working on something I'll want to test soon, but it wouldn't be terrible to test it at first on the mainnet.
Can you tell me which version of the client you are using? Then I'll try using the same version and see if it dies for me too.
Also, you know the "daemon=1" line makes the process detach from the terminal but keep running in the background, right? It can look like it 'died' because you get your shell prompt back, but it's still running if you check the process list. I doubt that's what is going on in this case, but thought I'd mention it just in case.
December 25, 2015, 01:18:30 PM
In the current situation, I understand it as a data gathering tool and a method to test the success of proposed changes.
The data is essentially an expression of users' perceptions, perhaps even users' perceptions of others' perceptions.
The threat of perceptual distortions introduced by pluralistic ignorance is an important issue to consider, especially given the inexpressiveness of the value transfer protocol. There is no mechanism to transfer value other than that which can be described with cryptography, specifically it is incapable of transmitting the societal values that are normally mediated by all the stuff that comes with embeddedness.
The lack of identity is a double-edged sword. It protects the individual from group coercion but it also robs the individual of the essential benefits of interpersonal relations with other group members, which is where the threat from pluralistic ignorance starts to come in.
No it isn't voting, but it is opinion polling and that's not exactly an under-developed field.
Quote
An expression of support for a 'petition' is essentially a statement that, given the update is released, that user will update their software.
That's one way of viewing it. I think opinion polling is a more accurate and more useful model of what's actually going on.
Quote
It is a means to independently prove that a threshold triggered-fork would be successful.
This is a social thing in essence and so all you're ever going to have to work with are warm fuzzies (aka “statistics”).
Cheers and Season's Greetings
Graham
December 25, 2015, 07:12:07 AM
I just checked, and it appears that the default ports for testnet have changed since the last official release.
I've updated the wiki page, but to fix it I think the following should work:
1) cct stop (stop testnet before messing with the ports)
2) edit clam.conf to have this instead of the existing addnode lines:
port=35714
rpcport=35715
addnode=54.247.189.77:35714
addnode=khashier.com:35714
3) cct (start testnet on the new ports)
I've updated the wiki page, but to fix it I think the following should work:
1) cct stop (stop testnet before messing with the ports)
2) edit clam.conf to have this instead of the existing addnode lines:
port=35714
rpcport=35715
addnode=54.247.189.77:35714
addnode=khashier.com:35714
3) cct (start testnet on the new ports)
Thanks. This does seem to make it connect, but my cct dies after about a second. I'll include the contents of my testnet/clam.conf and the output in testnet/debug.log in case it helps. I am working on something I'll want to test soon, but it wouldn't be terrible to test it at first on the mainnet.
testnet/clam.conf
Code:
testnet=1
rpcuser=clamrpc
rpcpassword=...omitted...
port=35714
rpcport=35715
addnode=54.247.189.77:35714
addnode=khashier.com:35714
daemon=1
testnet/debug.log
Code:
Clam version v1.4.17 (2015-09-23 21:07:15 -0300)
Using OpenSSL version OpenSSL 1.0.1j 15 Oct 2014
Startup time: 12/25/15 12:08:18
Default data directory /home/russell/.clam
Used data directory /home/russell/.clam/testnet
init message: Verifying database integrity...
dbenv.open LogDir=/home/russell/.clam/testnet/database ErrorFile=/home/russell/.clam/testnet/db.log
Bound to [::]:35714
Bound to 0.0.0.0:35714
init message: Loading block index...
Opening LevelDB in /home/russell/.clam/testnet/txleveldb
Transaction index version is 70509
Opened LevelDB successfully
LoadBlockIndex(): hashBestChain=0000135b14723652fecaeb07a52cebf3f69512594eae48d139956bca67552441 height=0 trust=65537 date=04/14/14 21:53:58
LoadBlockIndex(): synchronized checkpoint 0000135b14723652fecaeb07a52cebf3f69512594eae48d139956bca67552441
Verifying last 0 blocks at level 1
block index 2ms
init message: Loading wallet...
nFileVersion = 1041700
Keys: 103 plaintext, 0 encrypted, 103 w/ metadata, 103 total
wallet 1301ms
init message: Loading addresses...
Loaded 0 addresses from peers.dat 0ms
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 101
mapWallet.size() = 0
mapAddressBook.size() = 2
AddLocal(172.246.252.93:35714,1)
IPv4 venet0:0: 172.246.252.93
AddLocal(172.246.252.96:35714,1)
IPv4 venet0:3: 172.246.252.96
AddLocal([2605:f700:80:800::4958:58fc]:35714,1)
IPv6 venet0: 2605:f700:80:800::4958:58fc
AddLocal([2605:f700:80:800::5058:e517]:35714,1)
IPv6 venet0: 2605:f700:80:800::5058:e517
init message: Done loading
net thread start
addcon thread start
opencon thread start
msghand thread start
dumpaddr thread start
Added time data, samples 2, offset -2 (+0 minutes)
receive version message: version 60014, blocks=11524, us=172.246.252.93:35714, them=0.0.0.0:35714, peer=54.247.189.77:53536
December 25, 2015, 07:03:56 AM
I also thought the comparison of Proof-of-Stake to restricting voting to property owners is interesting. I tried (unsuccessfully) to shift the discussion to a different thread in the Politics section:
https://bitcointalksearch.org/topic/restricting-voting-to-stakeholders-1301042
But maybe it's not too much of a distraction here. In the other thread I only got two replies, one of which was scary:
https://bitcointalksearch.org/topic/restricting-voting-to-stakeholders-1301042
But maybe it's not too much of a distraction here. In the other thread I only got two replies, one of which was scary:
lets restrict it to white and maybe asian males
December 25, 2015, 04:17:26 AM
Also, the USA never distributed land to everyone who already owned land in another country. (I wonder which country Dogecoin would be in that scenario.)
While this is clearly a tangent to the main point of the discussion, I feel compelled to point out that the land that the USA did distribute was taken by blood from the people who already lived there.
December 25, 2015, 01:50:34 AM
navaman makes a really interesting point when you think about it. The requirement that voters own property (the male requirement is irrelevant to my point) may have been an implementation of a Proof-of-Stake model. Owning property is akin to having a stake in the future of a country, since your property would be worth less if the country does terribly. So really, it kind of fits together, albeit not completely.
Also, the USA never distributed land to everyone who already owned land in another country. (I wonder which country Dogecoin would be in that scenario.)
my guess would be Canada
j/k
December 24, 2015, 10:31:26 PM
navaman makes a really interesting point when you think about it. The requirement that voters own property (the male requirement is irrelevant to my point) may have been an implementation of a Proof-of-Stake model. Owning property is akin to having a stake in the future of a country, since your property would be worth less if the country does terribly. So really, it kind of fits together, albeit not completely.
Yes.
navaman complains about needing to have a stake in the coin to have a voice, but doesn't propose a better system. As Graham pointed out we can't have "one man, one vote" without requiring everyone to prove their identity. How would we prevent people from making multiple identities and getting multiple votes?
Being outraged that the people with the biggest stake have the loudest voices in the CLAMour system seems a little odd when we're talking about a proof of stake coin. Isn't the whole point of proof of stake that your stake size (rather than your hash power, or any other metric) determines the size of your influence over the network?
Yeah, the whole point of Proof-of-Stake.
When (loosely) applied to governance of a nation, it appears that Proof-of-Stake is an undesirable system. Of course, this tells us absolutely nothing about Proof-of-Stake's viability with regard to blockchains. You have to choose to be a part of CLAM. As far as nations go, you're just kind of born into one. You can also leave the system at any time with very little effort; in fact, it only requires that you do nothing for you to cease being a part of the CLAM network.Also, the USA never distributed land to everyone who already owned land in another country. (I wonder which country Dogecoin would be in that scenario.)
December 24, 2015, 04:40:48 PM
This system is very similar to the the early American restriction of voters to male property owners.
No it is not similar. One system requires voter registration whereas the other has no inherent notion of identities or individual accounts. They're as different as chalk and cheese.The term “petition” is semantically misleading in this context as it implies the existence of an authority able to grant the petitioner's request; no such authority can exist in a peer-to-peer networked cryptocurrency BY DEFINITION. This leads me to conclude that the approach itself rests on profoundly flawed assumptions and is unlikely to serve the advertised purpose.
There are other approaches that are suitable but I have rather a different model of the task, so it's moot whether they have any relevance to the specific context of what's intended to be achieved by the CLAMS petition approach.
Cheers
Graham
Semantics, particularly when it comes to 'crypto', are difficult.
Is it a wallet, an account, or a key ring?
Even the concept of a "confirmed" transactions is somewhat misleading; understanding that 'confirmation' is statement of probabilities.
In the current situation, I understand it as a data gathering tool and a method to test the success of proposed changes.
An expression of support for a 'petition' is essentially a statement that, given the update is released, that user will update their software.
It is a means to independently prove that a threshold triggered-fork would be successful.
Imagine, for instance, how the discussion concerning BTC privacy would change if the community had provable data to show super-majority support.
It becomes much more difficult to argue against, no matter what position of 'power' one might hold.
EDIT: For the record, I wanted to name it CLAMcensus
December 24, 2015, 04:32:46 PM
navaman makes a really interesting point when you think about it. The requirement that voters own property (the male requirement is irrelevant to my point) may have been an implementation of a Proof-of-Stake model. Owning property is akin to having a stake in the future of a country, since your property would be worth less if the country does terribly. So really, it kind of fits together, albeit not completely.
Yes.navaman complains about needing to have a stake in the coin to have a voice, but doesn't propose a better system. As Graham pointed out we can't have "one man, one vote" without requiring everyone to prove their identity. How would we prevent people from making multiple identities and getting multiple votes?
Being outraged that the people with the biggest stake have the loudest voices in the CLAMour system seems a little odd when we're talking about a proof of stake coin. Isn't the whole point of proof of stake that your stake size (rather than your hash power, or any other metric) determines the size of your influence over the network?
I don't believe his points are entirely invalid; just not very helpful.
As you and gjhiggins have put it, there is no concept of 'identity'.
I would suggest to navaman that the lack of 'identity' is a feature, not a bug.
Even if it does make difficult such ideas as "One person, one vote".
December 24, 2015, 04:22:33 PM
Yes.
navaman complains about needing to have a stake in the coin to have a voice, but doesn't propose a better system. As Graham pointed out we can't have "one man, one vote" without requiring everyone to prove their identity. How would we prevent people from making multiple identities and getting multiple votes?
Being outraged that the people with the biggest stake have the loudest voices in the CLAMour system seems a little odd when we're talking about a proof of stake coin. Isn't the whole point of proof of stake that your stake size (rather than your hash power, or any other metric) determines the size of your influence over the network?
It seems to me that navaman's biggest complaint is that he is not the imperial dictator of CLAM.
December 24, 2015, 03:26:47 PM
navaman makes a really interesting point when you think about it. The requirement that voters own property (the male requirement is irrelevant to my point) may have been an implementation of a Proof-of-Stake model. Owning property is akin to having a stake in the future of a country, since your property would be worth less if the country does terribly. So really, it kind of fits together, albeit not completely.
Yes.
navaman complains about needing to have a stake in the coin to have a voice, but doesn't propose a better system. As Graham pointed out we can't have "one man, one vote" without requiring everyone to prove their identity. How would we prevent people from making multiple identities and getting multiple votes?
Being outraged that the people with the biggest stake have the loudest voices in the CLAMour system seems a little odd when we're talking about a proof of stake coin. Isn't the whole point of proof of stake that your stake size (rather than your hash power, or any other metric) determines the size of your influence over the network?
Jump to: