 Show Posts
|
|
Pages: « 1 2 3 [4]
|
|
Address PM'ed, coins sent. (Sent 0.059 instead of 0.039 i mentioned @ PM.)
|
|
|
|
I had a different solution in mind, but maybe it might be merged into this one as well. cuddlefish's solution requires running bitcoind on the miner side. What if miners who don't want to run it could opt to get work from trusted work streams? - Pool keeps a list of authorized channels that it gets work from.
- Each channel supplies the server with signed block data, address set to one of pool's addresses.
- Miner picks as many of these channels as it likes, pool sends work from any one of them at random, signed by the channel owner.
This way, attacks would require everyone to choose channel(s) controlled by a single entity (unfeasible I think), traffic is low and miners wouldn't have to run bitcoind. What do you think? (As a further step, we could separate work servers from pools.) |
|
|
|
But yes, bigger pools have lower variability on proportional or score based schemes as well. So best way to solve the current problem would be taking away the control of the list of included transactions from the pools.
To do that you would have to modify the protocol. Go ahead and write a patch to do that. It won't be accepted into the official bitcoin client and I won't download any client that has that in it. I'm at a loss here. What's the connection with the protocol? And why would you object? What do you say to this proposal? Everyone gets all information from the network. You would have to modify the bitcoin protocol to limit someone from getting all information. It is a reactive response and against the ideals of the system. The thread does not solve any problem, it proposes an alternative and has nothing tangible to show yet. It was written when there were only a few other pools than deepbit. There are more alternatives now, there are 6-7 other pools and growing every week. It does not solve the fact that there are other pools and people aren't using them. I don't know what you mean by limiting someone from getting all information, or how it would be applied in this case. Maybe we aren't talking about the same problem. I haven't seen a proposal involving a protocol change in this manner. The basic idea is, if the pool operator doesn't have deciding power on the transaction list that gets in the block, a "public" pool, or any colluding group of them wouldn't be considered an attacker with high computing power. I'm not suggesting that there is an easy way to do that, but merely, if it could be done, it would solve the problem at hand. I don't have a clue how to do this with a protocol change, it's best if we approach this from the angle of, where the pool gets work from. The basic idea in the mentioned thread does solve this specific problem, if it can be feasibly implemented, which is something yet to be proven. Either way, I think it's a step in the right direction. Of course it doesn't solve the fact that there are other pools and people aren't using them, that's an unrelated matter. The idea is applicable whether there is only one pool or a multitude of them. |
|
|
|
But yes, bigger pools have lower variability on proportional or score based schemes as well. So best way to solve the current problem would be taking away the control of the list of included transactions from the pools.
To do that you would have to modify the protocol. Go ahead and write a patch to do that. It won't be accepted into the official bitcoin client and I won't download any client that has that in it. I'm at a loss here. What's the connection with the protocol? And why would you object? What do you say to this proposal? |
|
|
|
FWIW, this ceases to be a concern with the PPS payout scheme. I get my earnings from continuumpool almost instantly.
Sure, and you pay a 7% fee for that privilege. 5% Not a bad price to pay if you don't like variance. But yes, bigger pools have lower variability on proportional or score based schemes as well. So best way to solve the current problem would be taking away the control of the list of included transactions from the pools. |
|
|
|
I say again, the advantage of the biggest pool is the lowest payout variance. Pools like Eligius have some great features like zero fees, etc. but they suffer because sometimes they get zero blocks in an entire day. That never happens with deepbit. Deepbit gets a few blocks an HOUR most of the time.
Pooled mining is a natural monopoly for this reason. There needs to be some kind of technical fix, like the one previous linked in this thread.
FWIW, this ceases to be a concern with the PPS payout scheme. I get my earnings from continuumpool almost instantly. |
|
|
|
From a variance standpoint, Bitcoin's design makes the largest pools the most attractive. Which is bad for the security of the currency, and unfortunately an unavoidable result of how Bitcoin works. You can trust that people will "do the right thing" and move to smaller pools, or you can trust the pool operators not to abuse their power, but the whole point of Bitcoin was to avoid having to place that kind of trust in individuals.
Well, the individual miner is just in for profit and has nothing to gain from the pool's ability to disrupt the functionality of the network, so we could safely assume that s/he has an incentive to take away this ability from the pool. So, assuming that we have a mining system that does this with few enough disadvantages, almost everyone with significant stakes will switch. If this is possible, I wouldn't call the current problem an unavoidable result of how Bitcoin works. Here is one approach: https://forum.bitcoin.org/index.php?topic=9137Another could be creating a more distributed mining environment. For instance, we could embed an optional standardized pool functionality within mining software, that could be turned on at the user's will. Miners could constantly switch nodes that they get work. In this case though, a trust system or a sophisticated distributed accounting system would be needed. |
|
|
|
DNS is case insensitive. You've just found a bug in namecoind.
Namecoind is application-neutral, i.e. it doesn't do the conversions on behalf of the applications (domains being just one of them). We need a GUI tool to do all this. However, there already are online tools that can do the conversion, collision checking and even registration for you. As for the standard, this is from the extended specification draft:Name fieldName is a lowercase string, which begins with d/, followed by the domain name. Namecoin enabled resolvers will append the default TLD ( .bit) to the name specified here. Example: d/exampleThe IDNA standard encoding is used for internationalized domain names. This means that Unicode names need to be converted to ASCII compatible encoding according to IDNA, before registration. This can be done using the idn command-line tool: $ idn -p Nameprep ŝtelo
xn--telo-u5a
Also, only valid domain names are allowed, which means characters other than lowercase letters, numerics and dash are not allowed, as well as names longer than 63 letters and names starting with a dash. (Note: However, since this is a measure against compatibility issues with DNS, names consisting of all numeric values and underscore can be discussed.) Meaning, if the registered name contains Unicode characters, capital letters or symbols, it will be rejected by resolvers. |
|
|
|
Another potential problem is that hoarding bitcoins for long-term investment is so attractive that the flow of bitcoins becomes clogged up with very few people actually willing to use their bitcoins since the long-term investment prospect is so formidable. Early on the cost of one bitcoin was 1 dollar. Today it's around $7 if I remember correctly. In the future, with billions of users, the price of a single bitcoin could be $100,000!  So people today may want to hoard bitcoins like crazy. It certainly has an effect but in my opinion it's not as dangerous as it seems. When the BTC exchange value goes up, you can consolidate your profits by spending your money. That happened to me many times, the offers become more and more irresistable. You don't know if the value will go higher, maybe the market will crash soon. On the other hand, you can buy that diamond necklace with the bitcoins you've bought for only 100 bucks. Save some, spend some. At best, the deflation will make people more careful with their expenditures. |
|
|
|
I've been using Jabber video chat with my jabber.org account on my Nokia N900 and it usually works better than Skype. I don't know of any other clients (since I got everyone to buy an N900) but I'm sure there are.  |
|
|
|
Namecoin is neutral towards applications built on top of it, such as a domain name system. There is some brainstorming going on about other applications and their integration between each other. Needless to say, the current demand is focused on the DNS application of it, especially documentation, and also (hopefully) there will be a lot of development solely around this functionality. I see dot-bit.org as an encapsulating project focused on this endeavor. |
|
|
|
ns.bit is up. It is a DNS bridge for Namecoin. Make 78.47.86.43 your primary DNS server to start using it right away. Note that khal is also running a DNS bridge. The server can resolve ICANN and OpenNIC (.geek, .glue, etc.) domain names too, so it should be a drop-in replacement for whatever server you're using, though currently it's in an experimental state so you can experience downtimes. It maps Namecoin names to .bit, .c, .b and .n TLDs (i.e. ns.bit, ns.c, ns.b and ns.n are the same). This behavior will probably change as soon as there is a community decision on the standard TLD though, since it's not automatic in the case of DNS delegation (if you host your own DNS). Configuration examples:Simple address mapping ( example.bit → 1.2.3.4, www.example.bit → 4.3.2.1, etc.): $ namecoind name_update d/example "{\"map\": {\"\": \"1.2.3.4\", \"www\": \"4.3.2.1\"}}"Delegating the entire domain to a DNS server (like a DNS registry): $ namecoind name_update d/example "{\"map\": {\"\": {\"ns\": [\"ns1.example.net\", \"ns2.example.net\"]}}}"Delegating a subdomain to a DNS server: $ namecoind name_update d/example "{\"map\": {\"\": \"1.2.3.4\", \"www\": {\"ns\": [\"2.2.2.2\"]}}}"As discussed on the IRC, nameserver addresses can be IPs or canonical names. IPv6 support is in an experimental state, you're welcome if you can help me test it. A more capable scheme is in the works, so please contact me if you are working on a similar thing.
|
|
|
|
|
