Third, I do believe that there should be some incentive for quality work, but then you would have to pay someone every round to read through and place articles in a tier of their quality. Well, again, the purpose of devtome is to attract pageviews, so one can just measure unique pageviews and give some bonus to top 10%, for example... Of course, there needs to be some quality check... But I don't think it is hard to manage such stuff... It takes way more time to keep up with this humongous thread  |
|
|
|
It's not hard to compete with the internet when you are offering money. Content farms pay for content, so? This is all based on opinions of "content value".
...
And I think since we have only 20ish publishers right now, all we need to be is in development of something.
The content doesn't matter, as long as the ends are parallel with the goal of the overall project, which is to develop things into the real world, unless I am mistaken, that is what I got from reading the bounties. The IDEA behind Devtome is that advertisement revenue from Devtome will be used to buy devcoins on market, which will prop up the value of Devcoin. This is why Devtome is supposed to get 90% of all bounties... It is supposed to be a successful commercial project, not just a community wiki. So that is the value I'm talking about: content which brings in pageviews and, thus, revenue. (I believe that you need high-quality, unique, in-demand content to get them.) Devtome might be valuable in other ways, but it would be hard to justify allocation of 90% of bounties if it is not a commercial success. There is a plenty of other things which can be funded. |
|
|
|
I get this from it taking maybe an hour or two to write a thousand words The elephant in the room is that quality and importance varies greatly, and so does effort... The problem is that it is NOT additive, it is highly non-linear: sub-par content has almost no value, mediocre content has little value (there is a LOT of mediocre content on the internet), while high-quality content might have a great value... Devtome has no incentives for high-quality content, which means you get what...? That's basically same problem they had in Soviet Union: free market is much better at optimizing for quality/innovation than 'communism'. |
|
|
|
An exchange... That would be good. Give Vircurex some competition.
Exchange is problematic in many ways, there are many risks... Unless it is a crypto exchange, like powered by colored coins (This was a shameless self-plug ) OK, I'll give you my idea: a focused, specialized wiki. Devtome doesn't have quality of standards, so there are approximately zero reasons to search information specifically on devtome. It is theoretically possible that you will find well-researched information there, but it is also possible that you will find a stub or a low-quality article. In this way devtome competes with internet as a whole: on average, results you get on devtome won't be better that results you can get via google search. And it is hard to compete with internet Instead people could make sections on some specific topics and optimize for quality. E.g. a sub-wiki about Bitcoin. It should be updated very frequently, categorized very well. So that when I want to get information about Bitcoin, I have an incentive to go to devcoin-sponsored wiki and get high-quality information from it. It it doesn't sound cool enough, it is possible to market-incentivize creation of such topical sections: people should be able to invest devcoins into such sections... money which section gets from investments goes into improvement... which brings in revenue via advertisement... and that revenue is shared with investors. I think it is cool because people get a chance to invest into web sites they like... That's (probably) a new concept. And it can improve quality because there will be a competition between different sections, low-quality ones will die out, and high quality ones will attract visitors... at least in theory |
|
|
|
Maybe the lack of income from other sources has led to the estimations of how lucrative a wiki could become to have gotten out of synch with the nowadays lucrativeness of other projects? If we wwere running a cryptocoin exchange as well as the wki, which would make more money, I wonder? Maybe coding is no longer as non-lucrative as once it might have been? Or could be made so, if we could figure a way to get a cut for the project of the fruits of the labour/code? You're onto something... I'd say it's hard to invent something which will bring less revenue than wiki. Because, you know, content farm ( http://en.wikipedia.org/wiki/Content_farm ) is an old concept, and there isn't much money in this stuff because market is already saturated. For me, personally, it was obvious that it will turn out the way it turns out as soon as I've read description... Anyway, perhaps it would be better to brainstorm the ideas instead of continuing schadenfreude... One obvious idea is a game which uses devcoin as a currency. OK, we already have such , but plenty of different games are possible... It would be nice to have something which people could get into right away, like register and within a minutes start playing. I mean there is a whole spectrum between Satoshi Dice and Galactic Millieu... As for coding in general, it is a bummer that you need to get users _before_ you get any devcoin funding. This means that devcoin will never encourage people to start something new, at best it will encourage people to maintain what is already successful. Just an idea: you could finance hackathons. The idea is that a handful of developers can implement something startupish in 48 hours or so... So give them a sizable prize, like $1000 worth. Sure, 90% of such new projects will die right away, but 10% of them might get successful... even wildly successful. If devcoin will enable development of a new, interesting open source project, it would be great for PR... Much more so than, um, content farm. By the way, this thread gets completely out of hand, I can't keep up with it... Did you consider making offshots? |
|
|
|
Is there some way of making a portal page on the wiki itself, so devtome would keep getting the page views? Well, you can host many things on same domain; using a reverse proxy like nginx to merge them, for example. You can also make some custom module for wiki, if that's your thing... But it's likely easier to configure nginx than to develop a new wiki module, unless you happen to be a wiki module developer |
|
|
|
As far as I am aware there are no known vulnerabilities. It's just FUD. May I ask you what's your qualification? Forum bullshitter? There's a huge number of PPCoins traded daily and they are worth over 30 cents, if there was some known exploit it would have been carried out.
Do you even understand what kind of "exploit" we are talking about? |
|
|
|
All inputs and outputs should be sorted by color, with matching sort order. E.g. red inputs, blue inputs, uncolored inputs. Red outputs, blue outputs, uncolored outputs. This lead me to believe there was a "sort order", like ascending sorting by color ID or something. Now I realize there need not be any order, only that same colors should be adjacent (next to each other). This rule is basically a recommendation on how to create transaction, it serves for illustrative purpose, but it's now how you're supposed to identify colors. When client tries to identify color of a transaction output, it should follow the scheme described in "Order-based coloring" section, which means: 1. Color of each output can be found independently, they do not affect each other in any way. 2. Software MUST NOT try to validate transaction's coloring in any way. So, as I understand it, you are saying that each genesis tx out will be considered a separate color. By "does not mix with other colors" you mean that different colors of the same asset will not be lumped together? Yes. Some transactions might get larger because of this, but I think it's more important to have a reliable, working system than to optimize encoding. |
|
|
|
I understand that you were writing the spec in a hurry. Because you know what you were talking about. But for me it is a frustrating experience having to read a sentence many times over without it making sense. Yeah, sorry. I thought somebody will make a pull request... Because (according to the spec) a transaction involving multiple colored coins has to have all its inputs sorted by color. Where have you got it from? It is a recommendation, not a requirement. Let's say in the future there will be 1000s of colored coins floating around. So a p2p exchange has to know all the 1000s colors and has to scan the blockchain for each color, is that correct?
No, you don't have to know every color in existence to trace a certain color through the blockchain. Which is great! Yup, this was a design consideration. People are now working on a color server, by the way. And we have a thin client which kinda works, but has problems with performance. While we are at it, if all genesis tx outs are somehow marked in a blockchain, it is possible to make a very fast and simple server which knows about all colors in existence. It can easily scale to millions or even billions of colors without a problem. Sadly, marking genesis tx outs seems to be too much of a requirement... So we'll probably end up with two server designs, "fast" and "slow". Oh, BTW, as you're reading spects... There is an upcoming change to how multiple issues will work: Each issue (i.e. a genesis tx out) is a separate color which does not mix with other colors, but an asset can consist of several colors. This change eliminates a number of complexities. Basically it is much more straightforward and secure. It also enables us to create faster color-aware servers and clients and enables multi-issuer assets. |
|
|
|
take a look at the storage.js file (towards the end) hashes.push(key.slice(20));
can be change to: var txhash = new Buffer(key.slice(20), 'binary');
hashes.push(txhash);
basically, it was only reading the last input I already fixed this one, but I think there is another bug in getAffectedTransactions(): it only returns hashes for one addressm hashes for other addresses are forgotten. (Check how hashes are passed in steps.) |
|
|
|
Yes against a collision attack the effective strength is 2^160. This requires a (second) preimage attack rather than a collision attack. http://en.wikipedia.org/wiki/Collision_attackAs long as SHA-256 isn't broken, ypur only option is bruteforce... Or attack against ECDSA if public key is known. (Note: preimage attack isn't enough, it will merely give you a set of matching public keys which might make it easier to find a matching keypair. I'm just saying that preimage attack is required to utilize weakness in hash.) |
|
|
|
What you want is a rule that is a Nash equilibrium. It is in the best interests of a miner to stick to their current strategy as long as nobody else changes theirs. Well... What if there is some sort of collusion among majority of miners (i.e. they have more than 50% of hash power combined): they will agree to decide block to mine on top of using some set of rules and some sort of a practical Byzantine fault tolerant algorithm for synchronization? They can simply drop blocks of miners which do not agree to participate in this PBFT-synced collusion, and as far as I can tell it is stable as long as colluding miners have a majority. (I'm not quite sure about that, but I guess it will be 'stable enough' for practical purposes.) Within this collusion pretty much arbitrary rules can be enforced. |
|
|
|
Sorry, that's just a typo. Comment should be: sum(inputs) < sum(outputs). |
|
|
|
|
Here's the theory, as I see it:
To make sure that "transaction replacement rules" actually work, you need to discourage miners from breaking them. For example, punishing them in some way.
* Proof-of-work system must follow one main rule: longest valid chain wins. If you add other rules it becomes less stable. So it is hard, or even impossible, to add punishment as a rule, and you cannot punish miners in any other way because they are anonymous.
* In proof-of-stake system punishment is very straightforward: if there is evidence that miner have broken the rule, his stake is just destroyed.
Thus proof-of-stake system is more flexible: it allows you to create pretty much arbitrarily complex rules as long as they are verifiable using cryptography.
Multi-signature scripts and fidelity bonds allow us to create an emulation of proof-of-stake system within proof-of-work system.
So I think it would be great if people abandon fantasies about "transaction replacement rules" and will instead listen retep: his ideas are much more sound and implementable.
|
|
|
|
This revelation bothers me a bit, because the fact that already-final zero-conf tx are useless was not news to me. But the fact that tx replacement may also be useless for the same reasons is unfortunate. I hadn't considered that the same arguments applied. 1. Non-final transactions are still useful, you just shouldn't assume that you get automagic protection against double-spends. 2. You can protect against double-spends from your counter party using multi-signature scripts. Basically, contracts which assume that double-spending is not possible are sloppily designed. Rewrite them in such a way that multi-signature script will be used, and they will become safe. Moreover, they will become safe and implementable RIGHT NOW, not in a hypothetical future with ethical miners. Any contract which relies on transaction replacement rules can be made secure with help of a third party. So, basically, you do not need to rely on all miners being honest. You just need to rely on a third party which can be chosen by both parties of contract. As a bonus, fidelity bond can be used to make sure that third party has incentive to be honest. So you can locally emulate features of proof-of-stake system. |
|
|
|
My post was not about how it is at this moment, but under the assumption that tx-replacement become standard at some point. It would become standard under the assumption that it would be useful for a variety of things discussed in the community over the past couple years. I was just pointing out that it's not so clear-cut if you assume that miners will not follow "ethical" replacement rules. If there are miners who do not follow "ethical" rules than the whole concept of replacement rules is completely useless as these rules cannot be relied on. So we have two scenarios: 1. all miners are ethical: thus you can completely 2. some miners are not ethical: you cannot rely on replacement rules Are you talking about third case where miners can violate some rules, but always honor other? Half-ethical miners? |
|
|
|
(2): You have a non-final, replaceable transaction that is sitting in miners' memory pools, Currently non-final transactions are treated as non-standard, so they are not added to memory pools and are not propagated. And that's good... We are no longer restricted by transactions replacement rules. Which are no more than inconvenience: they provide no guarantees, but make it hard to use a contract which require a different kind of replacement. |
|
|
|
Double-spending is not yet much of an issue because very few merchants are vulnerable to it. You have the BlockChain.info mixer, and SatoshiDice and its clones. The latter easily respond by spending double-spend attempts 100% to fees, and proving their honesty after the fact by keeping records of the double-spend. From what I've heard a lot of merchants who have physical contact with customer (e.g. a restaurant) accept payments with zero confirmations. Each time this is mentioned on reddit, somebody says "don't worry, you just need to wait a couple of seconds". Yeah, right... Is it still possible to make transaction which is unlikely to be included into a block? Perhaps just low-priority one (freshly sent coins) and no fee. This will likely give you at least a few hours of opportunity to pull off a double-spend. So you can start once you're already far away from this merchant physically. Also, I doubt that merchant will notice that money disappeared and associate it with you.
Once this patch is ready I'll try to help with the front end. I'm currently working on web wallet, so double-spending might become shockingly easy =) |
|
|
|
You'll need to use armory to issue yourself a color and add it as /colordefs/<colorid>.colordef in settings dialog. It is possible to issue colored coins without ArmoryX: 1. Send coins to yourself, for example, to webcoin wallet from testnet faucet (e.g. http://testnet.mojocoin.com/ ) 2. Find transaction hash (in webcoin you can click button in tx view and it shows you txhash there) 3. Find output index of output which belongs to you. Unfortunately, http://blockexplorer.com/testnet shows transactions only after they are included into blocks, but our own block explorer can show them immediately: http://devel.hz.udoidio.info:3334/bexplo.html (Ignore color definition form field, paste tx hash and click show. you can find your output by value it is supposed to have. Note that it shows value in satoshis.) 4. Use this form to generate color definition: http://btx.udoidio.info:8080/ Name is up to your taste, unit is number of satoshis per unit of currency, for example 1. In textarea write txhash and outindex like this: df6b2f7bc5562b1209ba4b42ae2b0925e363bcb62962dfde50d694dc08b7b1d8:1 Public key is not needed. 5. After you click submit, it will show you color ID and link to color definition file. 6. If you indend to use it for Webcoin, you only need colorid, go to Webcoin (logo)->Settings->Color settings, add it as /colordefs/<colorid>.colordef 7. You now can see your balance in colored coins are issued. (Use a dropdown menu to switch.) 8. Don't forget that when you send colored coins, recipient should have color definition installed BEFORE he receives them, otherwise coins might get lost. |
|
|
|
0-conf transactions aren't replaceable by definition. The definition is the source code and it drops double spends against the memory pool. That's the whole point - peter wants to change the definition of what a zero-conf transaction means. It is snake oil: these rules provide no protection whatsoever, but users now erroneously believe that probability of double-spend attack is very low. Obviously, user who wishes to double-spend can communicate directly to miners who offer this kind of service. For example, I can implement Bitcoin Wallet Double-Spending Edition(tm) which will automatically create a double-spend for each transaction (if user ticks a checkbox) and sends a double-spending tx to a feed. Miners who wish to participate in this program will fetch transactions from this feed to get higher fees. So "definition in the source code" is absolutely irrelevant. Like I said, what's the downside to being laissez-faire about this? Live and let live. The market will sort it out. Miners aren't using replace-by-fee only because they do not care much about tx fees yet. Let's see how it will work in 4 years... By the way, I don't buy an argument that miners will care about keeping zero-conf payments somewhat secure. If zero-conf payments are accepted by merchants, then users do not care much when their tx will get into a block, so they will pay a tiny fee. So it is in the best interest of miners to show that accepting payments with no confirmations is insecure. Then more people will try to get their transaction into block as soon as possible, paying a competitive fee. I think it's fair to say that being unable to buy basic things like food or drinks in person would reduce the utility of Bitcoin for a lot of people.
It is crucial to buy food and drinks with plain Bitcoin transactions? There is a plenty of options: shared wallets, green addresses, multi-signature transactions... It is definitely possible to make payments ACTUALLY secure, it just requires a bit more effort... |
|
|
|
|
Show Posts
