 Show Posts
|
|
Pages: « 1 [2] 3 4 »
|
...
I consider the Bitcointalk community suicidal for ignoring me and censoring people who matter. In fact, Bitcointalk violated the First Amendment rights of United States citizens by banning people of merit.
...
It may or may not be worth pointing out that only the United States government can violate the First Amendment rights of US citizens. |
|
|
|
What I am wanting to create is a Bitcoin script that will do the following:
- check <data1> against <sig1>
- check <data2> against <sig2>
then only redeem if both sig checks work but *additionally* I need it to ensure that <data1> is identical to <data2> and that <sig1> is different to <sig2>.
Is this even possible?
If <data1> must be identical to <data2>, then essentially aren't you saying that you require two the following: - check <data> against <sig1> - check <data> against <sig2> Though it seems roundabout, OP_CHECKMULTISIG could potentially be used. If you put <data> in a null output and require 2-of-2 signatures that sign the output, then in effect that would mean <sig1> and <sig2> have to be valid signatures of <data>. Here's my cursory attempt. The problem with it (in addition to whatever problems I don't see) is that the scriptPubKey doesn't pass the "is_p2sh()" test since it's not "OP_HASH160 <20 bytes> OP_EQUAL". Since I'm not sure how far you're willing to go from Bitcoin in your endeavor, I figure I'll include this anyway. redeemScript: 2 <sig1Pubkey> <sig2Pubkey> 2 OP_CHECKMULTISIG scriptSig: 0 <sig1> <sig2> <serializedRedeemScript> scriptPubKey: // This part copies <sig1> and <sig2> to the alt stack for later.
2 OP_PICK OP_TOALTSTACK 1 OP_PICK OP_TOALTSTACK
// Normal P2SH stuff.
OP_HASH160 <redeemScriptHash> OP_EQUAL
// Bring <sig1> and <sig2> back from the alt stack. The top stack item will be true if they are not equal.
OP_FROMALTSTACK OP_FROMALTSTACK OP_EQUAL OP_NOT
At any rate, hopefully this will give you some ideas. |
|
|
|
There will be a full explanation and user guide available on the website once the client is squared-away.
I wonder if we should make an interim release with just Kef's CLAMour/CLAMspeech GUI changes merged in. xploited's "reindex" merge is big and largely untested. I don't know how long it will take before we are confident releasing it, or how we even get to that stage. Kef's changes are tiny in comparison - but maybe they depend on the changes I made which prompted the need for merging the reindex stuff in the first place. Also, I guess you have other stuff on your mind right now. Good luck with that!  IIRC the only change I made that depends on yours is the GUI for the "getclamour" RPC method. So, just the get-petition-by-pid form. Now that I think about it, there should probably be a GUI for the "getsupport" RPC method too...hmm. |
|
|
|
By inclusion I just ment on how the entire path from op_code creation to block inclusion by a miner would look. But I guess there also needs to be a limit to how much you can keep expanding it, without ending up with a full copy of Bitcoin Yeah, I see what you mean. OP_CHECKLOCKTIMEVERIFY is implemented for the Clams blockchain in branch develop. It will take a little more effort to get it implemented for Bitcoin. The way I've implemented it is such that you can specify data about the block that a script is in via a new tab, "Block", of the Stack Evaluator. In the following screenshot, I've set "Block height" to 800000.  |
|
|
|
There is a similar tool written in Javascript for Forth here: http://skilldrick.github.io/easyforth/What would be interesting you implement is a mock miner that can be configured. This way we can test the more exotic op_codes and understand how they would behave from a inclusion point of view in the blocks. Do you have support for BIP65 already? Seems pretty cool. About the mock miner: That could potentially be a useful plugin. I'm not sure exactly what you mean by an "inclusion point of view" though. BIP65 support isn't implemented. I've been putting it off in hopes that somebody else would implement it in python-bitcoinlib.  But the underlying script evaluation API in python-bitcoinlib will take some changes to support including block height and/or block time in the evaluation, so I guess other people have the same idea that I do. Ultimately I'll implement it regardless, since I need to put in a way to override opcode behavior based on what chainparams are active. For example, a blockchain like CLAMS uses a different CHECKLOCKTIMEVERIFY implementation than Bitcoin does. |
|
|
|
Alright, so I've done a lot on Hashmal since I last posted here. It really grew from a "Transaction Script IDE" to a full-fledged toolbox for cryptocurrency development. You can deserialize transactions/blocks, encode/decode addresses, etc. There's an entire plugin system. I've tried to keep the Github Wiki up-to-date with the all the plugins that Hashmal comes with. Here's a short list of what the new plugins that Hashmal includes do: - Deserialize transactions/blocks
- Encode/Decode addresses
- Retrieve blockchain data from block explorers or via RPC
- Create transactions from scratch
I'm currently working on a large refactor of the Stack Evaluator. Here is how it looks now (apologies for the big image):  The issue I'm currently dealing with is displaying the contents of an inner script (as in Pay-To-Script-Hash scriptSigs) in human-readable form. When I have issues like that solved, I'll merge it into the master branch. -- edit: For your viewing pleasure, here are a couple of examples with the latest changes: 7 7 7:  string literal:  |
|
|
|
I've registered an identity on testnet using CLAMour as follows: The tx c82f27a509bf2c04ffb037f683d8259894f273f8d8f849a8e0545879d5444a2c has CLAMspeech create clamour 1a762d2507760a436061029547245e434fa89da6e9d22cf07d6f8a6140b31f37 http://txti.es/1a762d25The text at the link is "Testnet identity 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5 (address mr1yhbGu64c83LtN5GBxPVPBb7XheNi8rH)". The "identity" can (in a sense) be looked up using the client: cct getclamour 1a762d25
{
"pid" : "1a762d25",
"hash" : "1a762d2507760a436061029547245e434fa89da6e9d22cf07d6f8a6140b31f37",
"url" : "http://txti.es/1a762d25",
"txid" : "c82f27a509bf2c04ffb037f683d8259894f273f8d8f849a8e0545879d5444a2c",
"confirmations" : 16
} While this would work, I think it's better to separate it from CLAMour. Also, I think I shouldn't say "identity" when what I really mean is "pubkey". Here's an alternative approach: The tx 6c08736d725217eeaf04dd3e1cc90ee17123f4361b7318fd9f68b02d87823b0b has CLAMspeech register pubkey 8b8070fe 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5 Here the hex "8b8070fe" is the 4 byte checksum of the corresponding address: mr1yhbGu64c83LtN5GBxPVPBb7XheNi8rH. A "getpubkey" command (like "getclamour") would be helpful. Thoughts? I'm not sure why you need to use any URL. The register pubkey 8b8070fe 039df70c1c46425ae4d3be53892949e17bebcbe30f419132441faab92677b220f5 one seems easiest. But the checksum is only valid for Bitcoin testnet. So unless you specify either "Bitcoin testnet" or "111" (i.e. Bitcoin testnet prefix byte), it would take 112 iterations of sha256d to verify the checksum, assuming the verifier starts at prefix_byte = 0. That's not a heavy burden, but it seems unnecessary. |
|
|
|
...
The CLAMour system did influence my thinking about registering identities. Are you suggesting I should use CLAMour directly for this purpose? Since the "getclamour" command is being added, this would be easiest for me. I was thinking I'd need to keep track of the registry in a separate database.
Someone could register an identity using clamour by publishing a tx with CLAMspeech:
create clamour <hash> <url>
where <url> points to text like "I have public key 02... (clam address x...). I offer escrow services under XYZ terms." which hashes to <hash>. Then the first 8 hex characters of <hash> could be used to refer to this identity in future CLAMspeech records. In order to interpret the identity, the "getclamour" command could be used.
To be clear, if the clam devs object to me using CLAMour this way I won't. Maybe the clam devs could be a more general registry not just for petitions. Something like
create identity <hash> <url>
and then "getidentity" that works the same way as CLAMour, but with a different "space."
...
I'm not sure exactly what your goal is, but it sounds like Namecoin could be a viable alternative. CLAMour is one application of the overall ClamSpeech system, created for petitions. So if you want to store identities, I would recommend something along the lines of 'create identity <hash> <url>' as per your example. At one point we explored a potential format for ClamSpeeches that included metadata before the rest of the ClamSpeech - a "category identifier." Ultimately something more plain-language was used. There are no enforced rules on the contents of ClamSpeeches (and I'm confident that there never will be), only on their lengths. So if somebody wants to store identity data in the CLAM chain, it doesn't really matter what anyone else approves of. If you do use the CLAM chain for identity data, there is one thing you should be aware of: The requirement that a petition be declared with 'create clamour <petition_hash> [<url>]' exists because petitions are identified by their first 4 bytes when voting for them (so multiple petitions can be voted for in one stake transaction). Since you probably won't need to refer to multiple identities in one ClamSpeech, you can just omit the 'create identity' step. Thus, you can simply put 'identity <hash> [<url>]' in a ClamSpeech instead of 'create identity <hash> [<url>]'. |
|
|
|
...
Why don't we get to vote in U.S. elections? The argument goes that the U.S. has an outsized influence in the world and certainly affects Europeans. The argument against it is obvious: only U.S. citizens should be able to vote in U.S. elections. But isn't this based on the same idea as restricting voting to property owners/stakeholders? If it's different, can someone explain why? I have mixed feelings. I would to some degree like to vote in U.S. elections. But it terrifies me to think of United Stations voting in Spanish elections.
It is indeed based on the same idea as restricting voting to property owners/stakeholders. I think that's more of a strength than a weakness. I see some pretty big problems with the premise of allowing, for example, the people of Spain to vote in USA elections. For one, you'd have to determine which countries the USA influences enough to warrant giving them suffrage. After that, you'd have to evaluate (or trust) each country's census data - otherwise, a potentially lucrative business in which countries sell their votes could pop up. There are also other issues involving the incentives of voters. If a country's people do not want to be influenced by the USA, they would vote for the worst candidate in hopes of reducing the USA's influence. For example, Russia is certainly influenced by the USA...you see where I'm going with this. Personally (American here), I couldn't point to Tajikistan on a map of only the -stans. Asking American politicians to appeal to the people of that country would be unreasonable. |
|
|
|
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.) |
|
|
|
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 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. |
|
|
|
|
Have tried it a little.
Feedback/bug report:
- Local time for each user is displayed with their Troll Box messages.
- The Troll Box is scrolled back up to the top of the log whenever you access it from another page.
Feedback/suggestion:
- When the "Mini Version" of the betting interface is shown, the parameters currently being used (i.e. payout multiplier, bet amount) could be filled in to it.
Overall, it's cool.
|
|
|
|
Clam has been added to https://alterdice.com for betting and recently to our new exchange. Bringing us to 12 supported currencies. That's great. I just tried the site out and was able to turn 400 satoshis into over 6 BTC exploiting a bug that a lot of new dice sites have. Here's the relevant line from your provably fair verification code: hashed_result = hashlib.sha512(str(seed_server) + str(seed_client) + str(roll_number)).hexdigest()
Stringing the client seed together with the roll number like that lets me make the same rolls twice: "x1"+"2" == "x" + "12"... (I reported this to the owner privately and he already shut the betting down to implement a fix, so don't bother trying to exploit it). Sounds like adding Clam was a great decision, alterdicecom. It could have been someone with less integrity finding that vulnerability. |
|
|
|
Voting is soon ready?
I'm hoping to add voting to Just-Dice today. I just made it. It's 23:09 Pacific. Reload the Just-Dice site. On the 'account' tab, you'll see:  And at https://just-dice.com/misc/clamour_weights.txt you can see how the JD wallets are currently staking. The number at the start of each line is the number of satoshis voting that way:  http://txti.es/clamour has a list of the petitions I know about so far. Change the behavior of the opcode CHECKLOCKTIMEVERIFY so that it behaves identically to Bitcoin's implementation. the above is one of the petitions. wtf does it mean? It's a very developer-oriented petition that I created mainly to show a possible use of clamour. CHECKLOCKTIMEVERIFY is an opcode used in transaction scripts; it can prevent coins from being spent until a certain block height. It's too technical to really be relevant. |
|
|
|
I expect BTC is much more deflationary (especially during this earlier period of time) than anyone realizes.
I strongly suspect probably even much more deflationary than you suggest, for purposes of the CLAM distribution. What is very important to realize that no Bitcoins (or DOGE or LTC) have to be lost for the corresponding CLAMs to be lost forever. The BTC/LTC/DOGE merely need to have moved from their original (as of early 2014) addresses and then those private keys not kept for no particular reason for the next two years, and then finally kept from now until they might otherwise end up getting claimed. That, and the fact that smaller (Bitcoin/LTC/DOGE) wallets are more likely to simply be lost than larger ones. (People don't necessarily back up their laptops with keys for small amounts coins on there, but they do store large outputs very carefully.) Thus the fraction of outputs that are lost is certainly much higher than the fraction of coins that are lost. I don't know how many of those "yellow" coins simply don't exist and claiming them is a literal impossibility, but has to be a lot. I've personally lost several DOGE keys out of laziness (why take the time to back up 200 DOGE?), and I suspect that many others have as well. Especially the new users that the DOGE community recruits. So, FWIW, there's some anecdotal evidence of your point. |
|
|
|
Our CLAM - The CLAMour Specification
Looking great. Thanks for all the work put into this. Not sure about the 10,000 block time frame though, it doesn't seem like enough time for a real vote to occur. Is the Clamour name a take on the word clamor? Yeah, "clamour" is the British English equivalent of "clamor." For the sake of brevity, it started as "clamor," but "clamour" has the words "our" and "clam" in it. About the 10,000 block frame: That's a moving frame. There is no deadline for votes; instead, whenever >50% of blocks staked in any 10,000 block window express support of a petition, that's considered a majority. So in effect, the vote can occur any time. I still don't really understand what's supposed to happen in the event of a successful vote. Can you expand on that? So far I gather that nothing really happens, it's just a metric you can use to assess whether x% of people are likely to run a new fork with your proposed changes. It'd be up to the petition-maker to implement any changes they'd like to see, and convince people to run the new version. Is that about the gist of it? Yes, that's about the gist of it. It provides evidence that the network is willing to accept a change to the CLAM protocol. The changes have to manually be made, but it is no longer up to the developers to prove that CLAM users want a change. In short, it protects users from tyranny and developers from blame. |
|
|
|
Our CLAM - The CLAMour Specification
Looking great. Thanks for all the work put into this. Not sure about the 10,000 block time frame though, it doesn't seem like enough time for a real vote to occur. Is the Clamour name a take on the word clamor? Yeah, "clamour" is the British English equivalent of "clamor." For the sake of brevity, it started as "clamor," but "clamour" has the words "our" and "clam" in it. About the 10,000 block frame: That's a moving frame. There is no deadline for votes; instead, whenever >50% of blocks staked in any 10,000 block window express support of a petition, that's considered a majority. So in effect, the vote can occur any time. |
|
|
|
...
So I add a coin generation transaction(still lost on how to do this)
...
The coin generation ("coinbase") transaction is a transaction with a null input - an input that appears to spend output 0xffffffff (the maximum output number) of transaction 0000000000000000000000000000000000000000000000000000000000000000. Each block is allowed to have only one. The transaction pays X coins to you, where X is the block reward. What separates it from any other transaction is that those X coins aren't actually being spent, they're being generated. |
|
|
|
Good MZC ideas here. A lot of us MZC devs (e.g. coders, artists, anyone that likes the project) are in different time zones, but we can usually manage to keep track of conversations in our IRC channel. The best place for collaboration is probably there or the subreddit, but it can be difficult to stay on top of the Altcoin Discussion forum so this may not be your best bet. |
|
|
|
|
