kiba
Legendary
Offline
Activity: 980
Merit: 1014
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2010, 07:51:05 PM |
|
Our code repository is non-existent and we're still debating the best route for DomainChain/BitDNS. * kiba is anxious.
|
|
|
|
satoshi
Founder
Sr. Member
Offline
Activity: 364
Merit: 7065
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2010, 09:02:42 PM |
|
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
Instead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2010, 09:05:36 PM |
|
Kiba, I wrote this response before Satoshi posted above. I'll need some time to understand Satoshi's post. Don't be anxious. I already said I thought it would take 2 weeks to agree design directions before coding. There has been excellent development over the past 24 hours. It has become clear that Gavin's changes to handling of non-standard transactions don't rule out domain registration integrated with Bitcoin. It is also becoming clearer that there is less distance between my DomainChains ideas and the theymos/nanotube design. Their design does not have the tangled ties with domain name server operators, that I previously thought it did. Hang in there! Two weeks will seem like nothing in the long term outcome.
|
|
|
|
nanotube
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2010, 09:20:40 PM |
|
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
sounds excellent in theory... The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ? very curious to hear your further thoughts on this. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
jgarzik
Legendary
Offline
Activity: 1596
Merit: 1099
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2010, 09:32:35 PM |
|
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
This sounds very very interesting, something to explore. Can you elaborate on how would it work in practice? Separate networks and block chains implies hashing one block header for each network, with different resulting hashes, does it not? The only thing I can come up with is the completely naive and slightly cache-unfriendly implementation... while (nonce < 0xffffff) nonce++ for each network data_block[nonce_offset] = nonce // ie. our nonce scanhash(data_block) or for each network while (nonce < 0xffff) data_block[nonce_offset]++ scanhash(data_block) I could easily update cpuminer to poll multiple RPC endpoints for 'getwork'...
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
jgarzik
Legendary
Offline
Activity: 1596
Merit: 1099
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2010, 09:49:06 PM |
|
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
Same incentive as the main chain -- you get paid.
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
Anonymous
Guest
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2010, 10:23:37 PM |
|
So if its possible to have a separate block chain and share the cpu power it seems like the issue is solved. Dont go pushing non financial transactions into one central block chain but let each application be a separate entity. If there are many different block chains it increases the chance of earning a block doesnt it?
Its a simple elegant solution from satoshi.
|
|
|
|
nanotube
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2010, 10:43:26 PM |
|
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
Same incentive as the main chain -- you get paid. but if you get paid just as much by mining pure bitcoin without the side hashing...
|
|
|
|
satoshi
Founder
Sr. Member
Offline
Activity: 364
Merit: 7065
|
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
The incentive is to get the rewards from the extra side chains also for the same work. While you are generating bitcoins, why not also get free domain names for the same work? If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too. You have one piece of work. If you solve it, it will solve a block from both Bitcoin and BitDNS. In concept, they're tied together by a Merkle Tree. To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch. In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal. You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility. We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes. Note that the chains are below this new Merkle Tree. That is, each of Bitcoin and BitDNS have their own chain links inside their blocks. This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain. This is two timestamp servers not sharing a chain.
|
|
|
|
Judson
Newbie
Offline
Activity: 22
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2010, 11:00:25 PM |
|
I agree with satoshi's idea. It seems like the best of both worlds.
|
|
|
|
da2ce7
Legendary
Offline
Activity: 1222
Merit: 1016
Live and Let Live
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 12:10:07 AM Last edit: December 10, 2010, 12:24:56 AM by da2ce7 |
|
If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
I'm still trying to get my head around your idea completely. The main reason that I liked the idea of including BitDNS into the bitcoin block chain via transaction fees is that it gives BitDNS a very comprehensive economic support using bitcoins, thus increasing the value and usefulness of bitcoins. I gather from Sotoshi's model, both BitDNS coins and bitcoins are generated by the same block, allowing them both to be traded as a commodity. The problem I see with that is that domain names have value from their name, registration costs, and bandwidth/computer cost , not scarcity in number. In nanotube's+theymos's proposal, the real cost making a BitDNS is _automatically_ paid by the transaction fee, their is no need to create a second market. As many or as little domains names will be included in the chain, and the generators will be compensated in bitcoins for providing that service.
|
One off NP-Hard.
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5306
Merit: 13296
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 12:18:00 AM |
|
Satoshi's idea eliminates the need for BitX. Alternative chains can be made without splitting CPU power.
Our version of BitDNS would never use its own chain, though, because creating domains should not be tied to a proof-of-work, and we therefore have no generation incentive.
120 bytes with an OP_CHECKSIG is enough for our proposal, I think.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
RHorning
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 01:23:10 AM |
|
So if its possible to have a separate block chain and share the cpu power it seems like the issue is solved. Dont go pushing non financial transactions into one central block chain but let each application be a separate entity. If there are many different block chains it increases the chance of earning a block doesnt it?
Its a simple elegant solution from satoshi.
While I like the idea in general, it doesn't really solve the problem in terms of parallel currencies. I don't think the idea of where the CPU power was going to come from for powering this network was ever an issue. People who got into mining would go wherever the money was at and find solutions to "earn" whatever coins happen to be around. I do like the idea of pooling Bitcoin-like block chains in terms of attempting to "earn" hashes, and if there were more ways use CPU power to generate hashes it can only be beneficial to everybody involved. I still would like to use miners for "authentication" of the DomainCoin registrations in some way and I'm trying to come up with a good system to get that done. By authentication I'm referring to basic "rules" that can verify that a domain hasn't been claimed, and a "miner" who doesn't follow those rules as accepted by the rest of the network gets that block rejected. That is happening right now with Bitcion in regards to transactions, but doesn't happen with any other data and won't happen with other data at least as it is presented. It still gets to the issue I presented earlier on another thread: I agree with jgarzik, the chain should not be used as storage.
If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain "dependent" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.
I think I've asked this question a number of times getting the run around. Perhaps I'll be more clear with this example as proposed by Caveden: If you create this alternate "proof of work" chain (presumably to keep this junk out of the main Bitcoin financial traffic), how can you get those who are performing this work to be paid in Bitcions, based upon some fee system agreed to by the network running that proof of work chain? If simply running that network is its own reward, it doesn't matter, but if there is going to be a fee involved for adding information into that proof of work chain, I don't see how that can be done without actually putting those block into the main Bitcoin chain, or setting up a completely parallel currency to Bitcoins. This is an intractable problem if you want to include the data itself in an authenticated form in a chain block and have that chain block directly connected to Bitcoin without a parallel currency. Theymos simply ignores the issue entirely with his protocol.... which is fine as far as that goes but a miner isn't really being paid to process domain registrations and certainly isn't authenticating bad registrations. The real "work" in terms of a DNS system is to authenticate precisely who "owns" the domain and make sure that somebody else can't claim that domain. The Theymos/Nanotube protocol forces authentication into a free good, and puts potential attacks on the protocol into the hands of the Bitcoin network... where I don't think it belongs either. I firmly believe that the data for domains must be in an authenticated system, preferably its own independent chain (perhaps linked to Bitcoin), where all of those serving this data can agree upon the same information and there is no ambiguity about the data. Previous proposals that shove the data into the transactions of Bitcoins fail to get that accomplished.
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 11:23:32 AM |
|
The incentive is to get the rewards from the extra side chains also for the same work.
You don't really get any extra reward. Either you are collecting generation fees + transaction fees from the Bitcoin side, plus some profits from the Domain Name side. Or, everything is in the Bitcoin block and you earn the same total profits, but all from the Bitcoin side (due to the additional Domain Name transaction fees on the Bitcoin side).
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 12:21:34 PM |
|
[edit: nevermind this post. I haven't been able to express my idea clearly here.]
Suppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.
To register foo.domain, the buyer pays 10 BTC using the standard Bitcoin system, then goes to the other system to claim their domain name. But how to know that they paid? They can prove cryptographically that the 10 BTC payment came from them, but they can't prove that the payment was for a domain name. They might be using that same payment to claim services from several separate sites.
So obviously Bitcoin needs a way to associate a transaction ID with a Bitcoin payment. If you can include a transaction ID (of say 64 characters), then you may as well just use the Domain Name details as the transaction ID (because it's short enough), in which case there's no need for a separate domain name registration chain.
A domain registration is just a Bitcoin Payment to an unspecified miner, with a transaction ID that happens to be meaningful.
|
|
|
|
bitcoinex
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 12:29:00 PM |
|
Introduction of BitX reduces the likelihood that will be invented a way to cut the chain?
Or is it generally no longer considered a necessity?
|
New bitcoin lottery: probiwon.com- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
|
|
|
RHorning
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 01:39:27 PM |
|
If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
In nanotube's+theymos's proposal, the real cost making a BitDNS is _automatically_ paid by the transaction fee, their is no need to create a second market. As many or as little domains names will be included in the chain, and the generators will be compensated in bitcoins for providing that service. The thing is that the miner receiving the transaction fee is just getting that as a sort of free lunch. The fee may be in place to cut out spammers, but they aren't doing any work so far as anything to do with the DNS system. Those computers which are processing and authenticating the raw data are not getting any sort of fee at all and the generators are not being compensated in Bitcions. All that is happening is that the miners are getting paid essentially as a data storage service entirely, and that is of marginal utility in my opinion. This is also why there are some huge complaints about using the Bitcion blockchain as a generic data storage system... rightfully so I might add. Suppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.
Let's assume for a minute we have another block chain which contains just domain data which is cryptographically hashed, but may or may not have proof of work (let's ignore that for now, which I'll address below). The purpose of the block chain is for the authentication of the data primarily where the "network" of domain servers can "certify" that the data fits the network rules and that domain data within that chain is valid in terms of who "owns" what domain. As a public block chain, it also shows what the majority of the "network" agrees ought to be in that chain too. Improperly formatted data that is not agreed to by the majority of the network is rejected from this block. Since it is a chain it also verifies against tampering and does a timestamp, and more importantly by being outside of the main Bitcoin chain it reduces the data payload for what is admittedly a specialized service which not all Bitcion users are necessarily interested in. These are the features of the Bitcoin transaction database that are being desired to be applied to other sets of data. So far that is the easy stuff. We also want to set up some system where the "registrar" putting data into this chain is going to be "paid" for the registration and authentication of this system. I emphasize this as this is both going to be a reason to be a registrar as to even exist as a registrar has a strong financial stake in maintaining the database to receive more registrations, and provides a reason to have fees to cut down on spamming domain names or abusing the public commons. The fees are being paid to maintain the database, which is the important thing here. Without this fee, at best this database is being authenticated and supplied to the world at large strictly as a public service for free. Some people like that but I hope that those involved with the Bitcoin project can appreciate how being paid for such a service can be very useful and motivating. The Theymos/Nanotube proposal and for that matter all registrations into the Bitcoin database through extra data in a transaction sidestep this issue entirely by ignoring authentication and only using the timestamp ability of Bitcoin, where this database would have to be built anyway but derived from Bitcoin and thus provided as a public service for free. Here is the real issue, however: Since there is no central server, the registrant wants to make sure their registration is put in by whatever registrar happens to be in line to put in the next record onto the block chain, however that is decided (by proof of work or some other agreed upon system). They want to send out some sort of generic transaction that can be received by the "authenticator" of their registration application who puts this registration into that block chain. Only if their registration is accepted into the block chain should that authenticator be paid. A problem arises here: A bitcoin miner may know that a fee is available from a registrant, but how do you decide where those coins properly belong? Keep in mind that once a fee is processed in Bitcoin, it is irreversible. If there is a chain split on the domain records due to a formatting/authentication dispute (it likely will happen just like it is happening with Bitcoin even now) those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block. Some other registrar may pick up the registration and simply out of the kindness of their heart decide to include it in another block, but they won't be receiving any fee at all for that service. Some system could be perhaps set up where after a block is down to a given depth in the block chain that the fee can be "released". Still, regardless of how you set this up there will be some trolls who will be collecting fees, pretending to put stuff into the domain registry but not really caring about the domain registry protocols and siphoning off the fees for themselves, perhaps in collaboration with a Bitcoin miner. Since this represents serious money, there will always be some trolls doing this. Even an "honest" registrar is still going to make some mistakes due to a bug or something similar which may on occasion capture fees when they are deserved under this system. I believe the fee system is critical to the success of this domain registration system. That ensures selfish behavior on the part of the registrars which puts it into their self-interest to maintain the databases, computer equipment, and everything else which makes this work. Yes, there are other ways that a domain name server can earn some coins, and perhaps that ought to be done too, but registration fees are already a part of the marketplace and something which this system is trying to capture as well. In short, I am trying to demonstrate here that the authentication simply must happen with an entirely different currency, or that authentication of the data (not merely the time stamping) must happen within the Bitcoin client and that data at least in some fashion or another included more directly into the Bitcion block chain with the data authenticated by the miner itself. A Bitcoin miner may choose not to process domain data, but some system must be set up that can certify that a given block including the domain data meets some sort of authentication standard to be accepted into the block chain to "earn" those registration fees. Otherwise the system falls apart and any talk of fees other than as a pure transaction fee to a Bitcoin miner alone is meaningless, with that transaction only to be used to preserve the transaction database. I am also suggesting that to ensure promptness of registration, that it may also have to be a separate currency simply because not all miners are going to want to bother with domain registration authentication and over time the latency of even getting a domain registration into the system may be intolerably long (on the order of days or weeks) depending on the setup of the Bitcoin network and other priorities of the miners. I'm not suggesting an alternate currency to drive this project out of Bitcoin as useless data, but to point out that it is unworkable even from the perspective of the goals of the peer to peer domain server concept too. Putting the data into transactions isn't authentication and is also losing much of the power of what Bitcoin offers in terms of the authentication too. The proof of work system as used by Bitcion is also the only reasonable way to ensure that the system stays decentralized in terms of deciding who gets to put in the next block. Certainly some sort of common protocol for finding the next proof of work hash can be set up through a common mining pool between multiple currencies like this, but that is a completely separate issue from if it is to be a separate currency or not which I don't think has been decided on this thread. The only other solution would be for Bitcoin to fully embrace this and other similar concepts that might come along and provide hooks and some sort of standard protocol to authenticate data of this nature on the main Bitcoin network. I think in theory that could be done and may be done in the more distant future in terms of "unifying" the proliferation of currencies that may result if it isn't done. I just don't see how that is going to get into the main Bitcoin chain anytime soon and even that has a whole bunch of drawbacks which I haven't fully explored either.
|
|
|
|
bitcoinex
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 02:41:39 PM |
|
I have not yet read all the posts but I have a few thoughts:
Need to divide the creation of a domain name and change of authoritative servers for him: First is the expenditure limited domain name space and must be expensive. Second only settings that can be changed frequently and should be generated in large quantities and cost little.
Names should be allowed to specify the relative and absolute value (with dot at the end). Absolute in case the system will supplement or replace the main in the conventional TLD.
Also names should be allowed to specify 3rd or more level domain names too.
|
New bitcoin lottery: probiwon.com- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
|
|
|
bitcoinex
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 02:51:50 PM |
|
I suggest tahoe lafs if you are looking for a database for storage.
Remember, speed is of the essence. We can alway replace the database with something else, but not time. All non-essential features should be blocked from implementation focus. That mean the core developers don't work on a fancy GUI. They will focus on: 1. The mechanism to mine, register, and change a domain name. 2. The mechanism to distribute or output the DNS database. 2. "powerdns" can work with plugins and with bind9 configs by default. We can write a plugin for it.
|
New bitcoin lottery: probiwon.com- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2010, 02:57:37 PM |
|
... Keep in mind that once a fee is processed in Bitcoin, it is irreversible. If there is a chain split on the domain records due to a formatting/authentication dispute ... those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block
That doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the "winning" chain gets the transaction fee. There is no "irreversible" payment to the generator in the "losing" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them.
|
|
|
|
|