Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMg<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=1790.msg27787#msg27787">Quote from: ribuck on December 07, 2010, 04:51:20 PM</a></div><div class="quote">OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove "generation" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.<br/></div><br/>The #1 disadvantage:&nbsp; My complaint about shoving useless and meaningless data into the transaction block.&nbsp; It would work, but there may be changes to Bitcoin to get rid of this "feature" as it may be seen as an attack rather than something useful for the project.&nbsp; I am not alone with this attitude.&nbsp; It also opens a pandora's box of problems down the line as domain information is hardly going to be the only thing to put into transaction chains in this fashion.&nbsp; Expect more resistance if you actually get a client to accomplish this task.&nbsp; Bitcion is not bittorrent.&nbsp; <br/><br/>Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer.&nbsp; It may be possible that the nature of the scripting language itself may be changed to specifically exclude a "payload" being used in this fashion.<br/><br/>Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion.&nbsp; You might put into the "payload" any sort of in here, but there is no reason for anything or anybody to recognize this data.&nbsp; Instead you would likely need some other application which is reading all of the transaction and either "accepting" or "rejecting" the domain registrations.&nbsp; Such acceptance or rejection would be completely arbitrary and there would not be any sort of clear "ownership" of any sort of domain, or any sort of consensus as to which domain record takes precedence in the actual domain usage system (aka the DNS end of this registration system).&nbsp; Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.<br/><br/>I admit that some of this could be worked out simply by saying that the first "registration" takes precedence, including in the same block.&nbsp; Other systems could be set up (likely as an external app) scanning transactions and pulling out domain records that would "apply" the rules which identify a valid transaction.&nbsp; Competing software could put in different "rules" for the same data as well and put different domains as valid.<br/><br/>It was also pointed out that transaction records can be dropped.&nbsp; For instance when you send a coin like this:<br/><br/>Generation Block -- &gt; Alice&nbsp; -- &gt; Bob -- &gt; Charlie<br/><br/>Since all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:<br/><br/>Generation Block --&gt; Charlie<br/><br/>And all of the previous transactions are ignored and "forgotten".&nbsp; If your registration record is in one of those other transaction blocks, it is then lost.<br/><br/>This could work.&nbsp; It would be real nice to see what Satoshi thinks of an "abuse" of the transaction scripts in this fashion.&nbsp; My own preference is to permit additional kinds of blocks as a separate payload that is linked into Bitcoins, where some clients may only read them to verify the block hash and then dump the data and other clients could keep the data for their own purpose.<br/><br/>BTW, one advantage to going this route is that it would not require any reboot of the network<br/><br/>I do have my reservations about the direction this is going, but I'm willing to have an open mind about it.</div> text/html