Title: Version 0.3.18 Post by: satoshi on December 08, 2010, 11:19:24 PM Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again - IsStandard() check to only include known transaction types in blocks - Jgarzik's optimisation to speed up the initial block download a little The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://bitcointalk.org/index.php?topic=1886.0). - getaccountaddress - sendfrom - move - getbalance - listtransactions Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/ Title: Re: Version 0.3.18 Post by: RHorning on December 08, 2010, 11:30:46 PM This is the first update to Bitcion that I'm not jumping on and grabbing right away, because I think the choice of checking transaction types in blocks is not necessarily a good thing... at least while the question is undecided in the community. It does impact the network but in a subtle and political way.
At the very least I wish that Satoshi would at least express his view on what he thinks about putting extra data into transactions beyond pure financial data into transactions, and I think this is only going to start an arms race for those who want to play with scripts and those who are trying to keep scripts "pure". All that has happened here is to simply lay the gauntlet down to get past the "IsStandard()" check and find transactions which can pass that test but still contain other data. Title: Re: Version 0.3.18 Post by: theymos on December 08, 2010, 11:41:42 PM At the very least I wish that Satoshi would at least express his view on what he thinks about putting extra data into transactions beyond pure financial data into transactions, and I think this is only going to start an arms race for those who want to play with scripts and those who are trying to keep scripts "pure". All that has happened here is to simply lay the gauntlet down to get past the "IsStandard()" check and find transactions which can pass that test but still contain other data. Yeah; it's pretty pointless. Why on Earth would any miner adopt this change, when it means that they will be getting fewer transaction fees due to the lost non-standard transactions? Title: Re: Version 0.3.18 Post by: theymos on December 09, 2010, 12:26:50 AM ArtForz (15+% of the network), tcatm (2Ghash/s), and doublec (pool maintainer) have stated that they will not use IsStandard. Non-standard transactions will therefore still be possible.
When I have time, I will produce a patch for Bitcoin that will remove all non-network-enforced restrictions on transactions, so that other miners can easily also be configured to include these transactions. Title: Re: Version 0.3.18 Post by: Cdecker on December 09, 2010, 12:35:51 AM I guess we have the first official release that is disputed by the majority of computation power, Bitcoin's coming off age :-)
I do however like that the changes are communicated in an open and unbiased way. One thing that would be nice is to have links to the particular Threads, Checkins, whatever to be able to track/understand changes more easily. Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 12:38:17 AM Please start your own block chain, rather than forking the network like this.
I hope it is clear the havoc that your push to include non-currency data is causing. Title: Re: Version 0.3.18 Post by: nelisky on December 09, 2010, 12:45:53 AM Please start your own block chain, rather than forking the network like this. I hope it is clear the havoc that your push to include non-currency data is causing. Wrong thread? Title: Re: Version 0.3.18 Post by: Gavin Andresen on December 09, 2010, 12:48:45 AM Yeah; it's pretty pointless. Why on Earth would any miner adopt this change, when it means that they will be getting fewer transaction fees due to the lost non-standard transactions? There's been exactly one block with non-standard transactions: http://blockexplorer.com/b/71036 ... and it contained no fees. HOWEVER: jgarzik, you're over-reacting, too. This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid. Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them. There will be no havoc. Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 12:57:10 AM HOWEVER: jgarzik, you're over-reacting, too. This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid. Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them. There will be no havoc. I never said it would cause a block chain split. It's more fundamental: a rules split. Forking the network implied a majority of miners not running mainline bitcoin transaction rules. theymos appears to be drawing a line in the sand, where he wants to convince most miners to stop paying attention to mainline bitcoin transaction validation rules. He's free to do that. And miners are free to validate what they want to. But this sort of split will make it more difficult to work on the network in the future, and de facto, opens the door to larding down the block chain with all sorts of non-currency-related data as being discussed in other threads. Title: Re: Version 0.3.18 Post by: RHorning on December 09, 2010, 12:59:22 AM HOWEVER: jgarzik, you're over-reacting, too. This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid. Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them. There will be no havoc. No, this isn't going to cause a block chain split, it is going to cause a fork of Bitcoin. I just hope that is thought through very well, and I don't think it has been. Since transactions aren't being forwarded that fail the IsStandard() algorithm, those who want to put "non-standard" transactions into a bitcoin chain must either hard-connect to a miner who would accept these transactions or force some sort of ad-hoc way of setting up a second tier in the network to find nodes that will accept these kind of transactions AND likely put them into a future block. That only one block may fail at the moment with this test is ignoring the current discussion where conceivably almost every block in the near future may have some form of these "non-standard" transactions. Title: Re: Version 0.3.18 Post by: slush on December 09, 2010, 02:15:50 AM Please start your own block chain, rather than forking the network like this. I hope it is clear the havoc that your push to include non-currency data is causing. Agree. I don't see any reason why non standard, maybe non-financial transaction should be inside financial block chain. Also don't understand why major miners are going to fork client. I thought this software is about currency. So I'm absolutely OK with last release and I already updated all my miners. I'm definitely NOT against software based on chains and personally will support any BitDNS effort, but, please, keep bitcoin chain consistent. Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 02:45:41 AM Transaction fees will pay for the generation of the chain in the future, therefore if the BitDNS guys (or any other group) want to include carefully crafted transactions in the chain, then they must include the appropriate compensation for the generators, or likely their transactions will be dropped.
Even later in the future, those who include extra things without compensation in their blocks will get their blocks orphaned by the chain. I for one will upgrade my client to v.18 until their come a time when it is profitable for me to accept non-standard transactions. Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 02:48:28 AM Transaction fees will pay for the generation of the chain in the future, therefore if the BitDNS guys (or any other group) want to include carefully crafted transactions in the chain, then they must include the appropriate compensation for the generators, or likely their transactions will be dropped. That will disadvantage people who use bitcoins for reasons unrelated to storing data in the block chain -- ie. as cash as intended -- because the "appropriate compensation" will prioritize their non-currency transactions over currency transactions. Title: Re: Version 0.3.18 Post by: jib on December 09, 2010, 02:50:37 AM That will disadvantage people who use bitcoins for reasons unrelated to storing data in the block chain -- ie. as cash as intended -- because the "appropriate compensation" will prioritize their non-currency transactions over currency transactions. No, it'll disadvantage people who refuse to pay fees. What they're storing in their transactions is irrelevant. Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 02:51:43 AM That will disadvantage people who use bitcoins for reasons unrelated to storing data in the block chain -- ie. as cash as intended -- because the "appropriate compensation" will prioritize their non-currency transactions over currency transactions. No problem with that! It will increase the competitive nature of generation, making Bitcoin harder to attack, and encouraging improvements to the generation network to support more transactions (to maximize profit). You've gotta love the free market! Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 02:57:41 AM No, it'll disadvantage people who refuse to pay fees. Rather, it will increase everybody's fees, and incentivize creation of a currency-only chain without all the data spam. Title: Re: Version 0.3.18 Post by: Judson on December 09, 2010, 03:02:06 AM I applaude this decision.
Why would anyone want to muddle up their nice distributed currency system, free from complex regulation from governments, and add a DNS system on top of it? How hard would that be to explain to someone's mom, who (conceivably), could be using Bitcoin in the future? There is plenty of transaction fees to be had when bitcoin builds a larger user base. We don't need non-standard transactions to make mining worthwhile The simpler Bitcoin stays, the better IMO. Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 03:09:12 AM Rather, it will increase everybody's fees, and incentivize creation of a currency-only chain without all the data spam. No, as no generators will want to block fee paying (profitable) transactions. When adding non-currency data into the block chain becomes common, then the there will become a strong economic incentive to increase the block size as necessary. Thus keeping the transaction cost down. In the long run, extra data in the chain will _reduce_ the relative cost of a currency-only transaction, because the currency-only transaction uses much less data, compared to the data transactions, per transaction. Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 03:14:00 AM Rather, it will increase everybody's fees, and incentivize creation of a currency-only chain without all the data spam. No, as no generators will want to block fee paying (profitable) transactions. When adding non-currency data into the block chain becomes common, then the there will become a strong economic incentive to increase the block size as necessary. Thus keeping the transaction cost down. Currency transactions would have to fight harder -- pay more fees -- to make sure they're processed in a timely fashion, due to all the non-currency data in the block chain. Increasing the block size does not reduce transaction fees. Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 03:32:39 AM Currency transactions would have to fight harder -- pay more fees -- to make sure they're processed in a timely fashion, due to all the non-currency data in the block chain. Increasing the block size does not reduce transaction fees. Sorry I have to disagree with you, the transaction fees are based upon the 'cost' to generator to include the transaction. The cost is directly related to the amount of data needed to be included. In the future there will be no 'hard limits' on block size, only the risk that the block will be rejected and orphaned by the chain as it is to large. When a generator deciding what transactions to include, if the network is already profitable with very large blocks, (eg. 20mb+ as they have much non-currency data in them), then including very small 'currency' transactions have a minute cost. For example, 20,000,000 vs 20,000,010. If the block chain is restricted to just currency data, there is much less incentive to improve the efficiency of handling large blocks data. Therefore the relative cost will be much greater... 500,000 vs 500,010. Therefore the transaction fees required for small amounts of data are likely to be higher on a system that only induces currency data. Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 03:46:06 AM Currency transactions would have to fight harder -- pay more fees -- to make sure they're processed in a timely fashion, due to all the non-currency data in the block chain. Increasing the block size does not reduce transaction fees. Sorry I have to disagree with you, the transaction fees are based upon the 'cost' to generator to include the transaction. The cost is directly related to the amount of data needed to be included. This is not an opinion; read the source. Transaction fees vary on total block size, not just transaction size. Thus, larger blocks == higher fees. Thus, more data spam, or more overall network traffic (currency or not) == higher fees. Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 04:07:08 AM This is not an opinion; read the source. Transaction fees vary on total block size, not just transaction size. Yes, that is what the source says for the moment, in the future I do not expect the generators to just arbitrarily follow the current rules, rather I expect the generators to be quite discerning in what rules they enforce or ignore. Yes, larger block will be more expensive, (eg. bandwidth, and risk of rejection costs), but as the average amount of data in the blocks increase, the _relative_ cost per data amount will go down. Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 04:29:54 AM These experiments are better suited for an alternate network and block chain. Leave the currency as a currency, and preserve the investments that many have already made in bitcoin.
It could be as simple as a patch that accepts "-datanet" and non-standard transactions, such as http://yyz.us/bitcoin/patch.bitcoin-datanet-fork (warning: demonstration patch, do not use; you would want a real genesis block for a production network) Title: Re: Version 0.3.18 Post by: nanotube on December 09, 2010, 06:19:05 AM consider also that it's possible to encode data into the bitcoin blockchain already, merely by specially crafting the transaction. (See the 'first' option on http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal#Overcoming_potential_resistance_bitcoin_developers.2Fcommunity ).
alternatively, only timestamping and proof of expense (i.e., a regular transaction with a fee) may be used, pushing off the actual data storage off to external service (see 'third' option, ibid.) but why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? it seems that in the net, these side-band uses of bitcoin will only serve to increase the security of the network, by increasing the mining incentive, and bringing on more generation power. Title: Re: Version 0.3.18 Post by: davout on December 09, 2010, 07:10:30 AM I guess we have the first official release that is disputed by the majority of computation power, Bitcoin's coming off age :-) I do however like that the changes are communicated in an open and unbiased way. One thing that would be nice is to have links to the particular Threads, Checkins, whatever to be able to track/understand changes more easily. You already have that Title: Re: Version 0.3.18 Post by: chaord on December 09, 2010, 07:17:12 AM but why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? it seems that in the net, these side-band uses of bitcoin will only serve to increase the security of the network, by increasing the mining incentive, and bringing on more generation power. I personally agree with nanotube's point here, especially in light of the fact that arbitrary data can already be disguised in standard transactions if a person is motivated enough. I have not looked at the source code, but from what I understand I think that a much more pleasant (politically and technically speaking) solution would be to: by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)? I would like to hear why the above option was thrown out by the developers. While I agree that bitcoin transactions themselves should be the primary use of the blockchain, a good currency need not ostracize itself either. Title: Re: Version 0.3.18 Post by: theymos on December 09, 2010, 08:17:19 AM by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)? I would be happy with 128 bytes of arbitrary data. But it seems pointless for the official Bitcoin client to attempt to "legislate" any restrictions of this type when all miners have an interest in including any and all fee-carrying transactions. As long as these restrictions exist, miners are incentivized to: - Remove the restrictions to get more fees - Connect to as many peers as possible to get a higher chance of catching any non-standard transactions that would be produced, further increasing the load on those few nodes accepting incoming connections. The restriction on relaying these transactions should be removed, at the very least. Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 08:38:27 AM by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)? I would be happy with 128 bytes of arbitrary data. But it seems pointless for the official Bitcoin client to attempt to "legislate" any restrictions of this type when all miners have an interest in including any and all fee-carrying transactions. As long as these restrictions exist, miners are incentivized to: - Remove the restrictions to get more fees - Connect to as many peers as possible to get a higher chance of catching any non-standard transactions that would be produced, further increasing the load on those few nodes accepting incoming connections. ...unless the use of bitcoin for non-currency purposes discourages currency use. Some uses of the network can act as an overall disincentive against mainstream use. If people see that miners care little for currency transactions on the bitcoin network, or all the data spam increases TX fees to annoying levels, currency users will find a new network elsewhere. If people find out law-enforcement-objectionable data such as "kiddie-pr0n.p2p DNS data" is being managed on this network, that increases the incentive for currency users to go elsewhere. Maybe that makes some miners happy in the short term, and you happy, but I'm here for the revolutionary new type of digital cash. And this generalized data timestamping/notary service seems like it has the distinct probability of degrading service for digital cash, if it is even remotely successful. Title: Re: Version 0.3.18 Post by: sturle on December 09, 2010, 08:55:05 AM by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)? I would be happy with 128 bytes of arbitrary data.It doesn't get any faster by adding junk to the blocks. I don't get it? Why is it so important for people here to make Bitcoins slow and inefficient? Fees? Come on, miners! How much do you make from fees? Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 09:16:01 AM Fees? Come on, miners! How much do you make from fees? Not much, ;D I've made about 0.5 BTC from fees. It is just too profitable to just mine for the hell of it, I get 50 BTC each time I make a block, and (if I'm very lucky, I make 0.05 BTC from fees). About the large chain size, this isn't a issue, in the future it will be possible to 'prune' the chain with balances. This will reduced the size by a vast amount. When extra data is included in the chain, it is likely to be forgotten by (most) the network if it stops being important. For example, the BitDns guys will keep a relocation of a the DNS data for ages, however the banks are likely to just keep the bitcoin currency transfer data and drop the rest. Title: Re: Version 0.3.18 Post by: m0mchil on December 09, 2010, 09:20:36 AM There are many questions still unclear about bitcoin. We have yet to see a lightweight client, freed of the block chain's burden. We still have to see how the TX fee market will develop. There is uncertainty about what the average number of transactions per minute would be in, say, two years.
Distributed DNS using bitcoin concepts is really cool. But isn't this a separate currency/commodity? Why not create a separate chain for it? Why force bitcoin users to support services they aren't aware of? What if I want only BitDNS? And I don't need the payments stuff? Title: Re: Version 0.3.18 Post by: Timo Y on December 09, 2010, 09:21:06 AM You've gotta love the free market! We should not trust the "free market" blindly. The problem is that including a lot of data in a block creates costs, not just for the miner who includes the data, but for all other miners and all other users, for all eternity. In the current implementation, the user is passing on the costs to the miner, and the miner is passing on the costs to the rest of the network. However, the user's transaction fee only compensates the miner's costs. As long as this tragedy of the commons situation hasn't been sorted out, the free market won't fix anything. Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 10:02:32 AM In the current implementation, the user is passing on the costs to the miner, and the miner is passing on the costs to the rest of the network. However, the user's transaction fee only compensates the miner's costs. Current implementations, in the future the clients will only keep the stuff they care about. The DNS client will keep the DNS stuff, the bitcoin currency traders will keep the currency transactions. Let the generators worry about the chain; if bitcoins become worthless, then they will not have any incentive to generate! I for one have lots of faith in the free market, after all I'm a laissez-faire capitalist ;D, I will be voting will my generation. I suggest you invest in more that 50% of the generation network (or with like minded people), and ignore my the block I generate if you disagree with the data they contain. That is the life in a free market. When we all bought into bitcoin, we all knew that then network is dictated by the majority of generation power. All I'm arguing is that the generators will look out for their best interests, and their interests happen to fit very nicely with bitcoin: A strong bitcoin currency. Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 10:07:38 AM I propose a law:
"He who makes the chain, gets to decide what it looks like" Title: Re: Version 0.3.18 Post by: sturle on December 09, 2010, 10:57:47 AM I propose a law: This could work combined with:"He who makes the chain, gets to decide what it looks like" "Everyone can choose to accept a block or discard it" I don't want everyone to be spammed by blocks full of junk, and prefer to try to nullify it by generating a competing block without including the junk. The junk will of course make it eventually, unless the majority of miners switch on their spam filters. Title: Re: Version 0.3.18 Post by: ShadowOfHarbringer on December 09, 2010, 01:51:20 PM Well I spport Satoshi completely in this matter.
Leaving a possibility to store data in bitcoin chain is an accident waiting to happen. Just wait until somebody encodes kiddie porn into the chain - it would stay there forever. And the governments would have a perfect propaganda possibility for fighting it. "Normal" people won't use bitcoin at all if it is associated with perverts, mafia, and financial scams. Title: Re: Version 0.3.18 Post by: satoshi on December 09, 2010, 02:37:05 PM New transaction templates can be added as needed. Within a few days, there will be plenty of GPU power that accepts and works on it. Network support will be thorough long before there'll be enough clients who understand how to receive and interpret the new transaction.
Timestamp hashes are still already possible: txin: 0.01 txout: 0.00 <appid, hash> OP_CHECKSIG fee: 0.01 If there's an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps. I like Hal Finney's idea for user-friendly timestamping. Convert the hash of a file to a bitcoin address and send 0.01 to it: I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address. The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file's existence. I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done. Title: Re: Version 0.3.18 Post by: Gavin Andresen on December 09, 2010, 02:51:07 PM by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)? I would like to hear why the above option was thrown out by the developers. Several months ago, around the time when the 0.3.9 bugs were found, I privately told Satoshi that I thought whitelisting acceptable transaction types was a better way to go, rather than blacklisting transaction types that we find out cause problems. The danger is similar websites that try to blacklist <script> tags in HTML entered by users to prevent cross-site-scripting hacks. See http://ha.ckers.org/xss.html (http://ha.ckers.org/xss.html) for a nice sampling of how creative hackers can be. I haven't asked Satoshi if the recent discussion of BitDNS putting extra data in the block chain swayed his opinion or if he woke up in the middle of the night and realized that a creative use of OP_SOMETHING might lead to an exploit. I don't think it matters; I'm still convinced that whitelisting acceptable transaction types is the right thing to do. As for "the above option was thrown out by the developers" -- nothing has been thrown out! Again, I haven't talked to Satoshi, but I'm open to the idea of a third 'standard' transaction type that includes extra, arbitrary data. Lets have that discussion, implement it on the -testnet, poke at it, try to imagine all the possible ways it can be misused, try to estimate the benefits and costs... and if there's general consensus that it is a good idea, roll it into production. Title: Re: Version 0.3.18 Post by: satoshi on December 09, 2010, 03:17:53 PM I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.
why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? That's already possible. <pubkey> OP_CHECKSIG. <pubkey> can be 33 to 120 bytes.I also support a third transaction type for timestamp hash sized arbitrary data. There's no point not having one since you can already do it anyway. It would tell nodes they don't need to bother to index it. Title: Re: Version 0.3.18 Post by: Timo Y on December 09, 2010, 03:27:10 PM Just wait until somebody encodes kiddie porn into the chain - it would stay there forever. It is impossible to completely prevent that kind of abuse unfortunately. For example, someone could encode information in the decimal figures of amount sent, or in a "vanity plate" Bitcoin address. Probably not practical for jpeg or mpeg files, but for other low-bandwidth "illegal data" such as Blu-Ray keys, this is bound to happen sooner or later. Even "low bandwidth kiddie porn" could create big problems for us one day. All over the world, legislation is becoming more draconian every year and in some countries even the "wrong" kind of fiction and poetry is now considered kiddie porn by the courts and thus illegal. Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 04:50:48 PM I also support a third transaction type for timestamp hash sized arbitrary data. There's no point not having one since you can already do it anyway. It would tell nodes they don't need to bother to index it. Yes it is possible already. But it is disappointing to encourage main bitcoin chain to be used for generic data storage. When a large amount of users are non-currency data users, currency users will face longer delays, higher costs, and decreased ability to send free transactions. Currency users will be discouraged by these factors from using bitcoin. All these folks talking about the glory of the free market conveniently omit that there only one, monopolized market right now -- the mainline chain. This implies decreased competition versus many markets (==many chains) and tragedy of the commons, as everybody shoves all their data onto the main chain. An alternate chain that encourages data storage would better serve data users, leaving the main chain to better serve currency users. Title: Re: Version 0.3.18 Post by: ShadowOfHarbringer on December 09, 2010, 05:03:09 PM Just wait until somebody encodes kiddie porn into the chain - it would stay there forever. It is impossible to completely prevent that kind of abuse unfortunately. For example, someone could encode information in the decimal figures of amount sent, or in a "vanity plate" Bitcoin address. Of course, but that is not my point. The point is that if would possible to store extra data in Bitcoin protocol by design, then government would have the argument like "you can store extra data (including kiddie porn) - protocol is designed that way and default client allows it". Taking this possibility away in the default client takes that argument away and makes Bitcoin much more resistant to kiddie-porn-propaganda-attack. Title: Re: Version 0.3.18 Post by: ribuck on December 09, 2010, 05:12:34 PM When a large amount of users are non-currency data users, currency users will face ... decreased ability to send free transactions. There would be no incentive for a miner to process free domain name registration transactions. Broadening the use of the Bitcoin chain strengthens it. If 55% of currency users generate maliciously, they can corrupt the chain. But if there are also domain name registrars generating, you would have to corrupt 55% of them too, and different interest groups aren't corruptible in the same way. Satoshi has created a wonderful bird, but if his early adopters don't allow it to soar it will never achieve its potential. Title: Re: Version 0.3.18 Post by: ribuck on December 09, 2010, 05:15:35 PM The point is that if would possible to store extra data in Bitcoin protocol by design, then government would have the argument like "you can store extra data (including kiddie porn) - protocol is designed that way and default client allows it". DNS Records can contain arbitrary text records, but that has never been a problem. Interestingly, the same kinds of arguments are heard against using the TXT records for unofficial purposes, but the DNS system hasn't yet collapsed. On this forum we regularly contemplate putting Bitcoin addresses into DNS TXT records. How ironic that there is resistance to putting DNS data into Bitcoin! Title: Re: Version 0.3.18 Post by: galeru on December 09, 2010, 06:05:35 PM The white paper allows for individual servers to drop transactions, so long as they maintain the hashes in the Merkle Tree. So eventually, once the transaction server software is more advanced, the DNS servers could delete all the non-DNS server transactions, which would reduce it's storage requirements, and all the currency people can delete extraneous DNS transactions.
It is a tree, so it would be best if all transactions of each type were grouped so that you could delete one node, and reduce the Merkle Tree as much as possible. Otherwise, all other transactions do is increase the number of transactions. Also, as far as adding new data into transactions, maybe the best way to go about it is to introduce the data to the actual blockchain only when we also have the granular controls on mining and what people want included when they mine, and for what fees. I think having a well thought out fee data distribution is going to end up crucial to bitcoin, so that way when bitcoin users go to make transactions, they can determine the likelihood of their data getting into a block. Until we have this more effectively thought out, all the non-bitcoin stuff like BitDNS should go into the testchain. Title: Re: Version 0.3.18 Post by: sturle on December 09, 2010, 06:51:09 PM DNS Records can contain arbitrary text records, but that has never been a problem. Interestingly, the same kinds of arguments are heard against using the TXT records for unofficial purposes, but the DNS system hasn't yet collapsed. DNS doesn't push data on everybody. You have to ask specifically for the TXT record from the server serving the domain. Most requests are for A records, which are as as small as possible.On this forum we regularly contemplate putting Bitcoin addresses into DNS TXT records. How ironic that there is resistance to putting DNS data into Bitcoin! DNS can also be abused to send arbitrary data. I'm a happy user of iodine (http://code.kryo.se/iodine/) myself to tunnel IP over DNS (encrypted) when I want to use some wifi hotspot for free. But the traffic only go between me, the hotspot DNS server and my own DNS server. I don't push all my encrypted internet traffic to every DNS user in the world. I'm sure DNS would have been redesigned long ago if this was even possible. Title: Re: Version 0.3.18 Post by: ribuck on December 09, 2010, 06:57:31 PM ... I don't push all my encrypted internet traffic to every DNS user in the world ... Bitcoin's distributed nature is its strength, not its weakness. As bitcoin grows, there will be generators who operate large server farms that have no trouble with the network and storage requirements. And there will also be people who use Bitcoin through various cut-down solutions. Title: Re: Version 0.3.18 Post by: jgarzik on December 09, 2010, 07:48:41 PM When a large amount of users are non-currency data users, currency users will face ... decreased ability to send free transactions. There would be no incentive for a miner to process free domain name registration transactions. Actually, the miner's incentive -- for currency or data transactions -- is in seeing free transaction space disappear so that transactions cost money. In a system where non-currency data transactions are encouraged, which clearly raises traffic levels (over a currency-only chain), collectively costing everybody more money. Quote Broadening the use of the Bitcoin chain strengthens it. If 55% of currency users generate maliciously, they can corrupt the chain. But if there are also domain name registrars generating, you would have to corrupt 55% of them too, and different interest groups aren't corruptible in the same way. Yes, it strengthens the chain -- but if the bitcoin chain is processing (say) the majority of .p2p DNS records, currency users have to fight for space, paying higher fees to do so. Makes miners happy, and currency users unhappy. Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 11:27:10 PM Yes, it strengthens the chain -- but if the bitcoin chain is processing (say) the majority of .p2p DNS records, currency users have to fight for space, paying higher fees to do so. Makes miners happy, and currency users unhappy. This has already been covered, if the block is already full of profitable data (all with reasonable transaction fees), then there is a _strong_ economic incentive for a majority of the generators to increase the block size. Thus allowing more transactions and other data into the chain, allowing them to collect more fees. The entire block chain system, when paid for by transaction fees, is self balancing. Title: Re: Version 0.3.18 Post by: da2ce7 on December 09, 2010, 11:31:50 PM New transaction templates can be added as needed. Within a few days, there will be plenty of GPU power that accepts and works on it. Network support will be thorough long before there'll be enough clients who understand how to receive and interpret the new transaction. I agree with the whitelisting, this allows the generators to be more discerning in what they accept or reject. That said, as soon as the template for a good BitDNS implementation is released, I'll be sure to add it to my generators whitelist. Title: Re: Version 0.3.18 Post by: abstraction on December 10, 2010, 04:09:04 AM If I make a flaw in reasoning, please tell me where I went wrong.
It seems to me like the trend for data and data processing will be cloud based. Currently, the clouds out there are proprietary. Is it not unreasonable to expect that one decentralized cloud will emerge in the long run? And if so, can't the data and the instructions about what to do with the data just be stored in the cloud? So the only extra data needed in the block would be an address to the instruction set already stored in the cloud, and the receiver just accesses the instructions from the address. I don't have a strong understanding about encryption, though. Will (or can) the instruction address in the block data be encrypted so only the sender and receiver know what it is, or have the right credentials to access the instruction set in the cloud? Title: Re: Version 0.3.18 Post by: jgarzik on December 10, 2010, 04:11:40 AM Yes, it strengthens the chain -- but if the bitcoin chain is processing (say) the majority of .p2p DNS records, currency users have to fight for space, paying higher fees to do so. Makes miners happy, and currency users unhappy. This has already been covered, if the block is already full of profitable data (all with reasonable transaction fees), then there is a _strong_ economic incentive for a majority of the generators to increase the block size. Thus allowing more transactions and other data into the chain, allowing them to collect more fees. Sure, the miners collect more fees. Sure, the block limit will increase. As the block chain gets stronger and provides more valuable service, it gets more expensive for each user to use that service. End result, currency users pay more as more non-currency data transits the block chain. Title: Re: Version 0.3.18 Post by: da2ce7 on December 10, 2010, 05:33:40 AM Sure, the miners collect more fees. Sure, the block limit will increase. As the block chain gets stronger and provides more valuable service, it gets more expensive for each user to use that service. End result, currency users pay more as more non-currency data transits the block chain. No, economically speaking, when something is produced in larger quantities the cost per unit goes down. This is because any overhead for the production in relative terms has less effect on the cost per unit. I see no reason why a larger block would be any different. A larger block allows the generators to make more profit at a lower price per data unit charged. This encourages more people to use the service, thus increasing the incentive to generate. It is a win-win situation. Title: Re: Version 0.3.18 Post by: jgarzik on December 10, 2010, 07:02:46 AM Sure, the miners collect more fees. Sure, the block limit will increase. As the block chain gets stronger and provides more valuable service, it gets more expensive for each user to use that service. End result, currency users pay more as more non-currency data transits the block chain. No, economically speaking, when something is produced in larger quantities the cost per unit goes down. This is because any overhead for the production in relative terms has less effect on the cost per unit. I see no reason why a larger block would be any different. In some possible future where transaction fees are calculated differently from today, and block size limits are different from what they are today, and a bunch of other conditions are different from the network rules and source code we have today, we'll see how it all shakes out. Title: Re: Version 0.3.18 Post by: sturle on December 10, 2010, 07:37:19 AM ... I don't push all my encrypted internet traffic to every DNS user in the world ... Bitcoin's distributed nature is its strength, not its weakness. As bitcoin grows, there will be generators who operate large server farms that have no trouble with the network and storage requirements. And there will also be people who use Bitcoin through various cut-down solutions. Title: Re: Version 0.3.18 Post by: ribuck on December 10, 2010, 11:14:14 AM It is in our interest that it would still be possible to run Bitcoin on normal home computers in the future as well. It's likely that the continuing increases in storage capacity and drop in price per gigabyte will mean that it gets easier, not harder, to run Bitcoin on normal home computers. There is also the potential for block chain compaction which will reduce the storage requirements for a fully-functional home computer Bitcoin.Title: Re: Version 0.3.18 Post by: sturle on December 10, 2010, 12:39:19 PM It is in our interest that it would still be possible to run Bitcoin on normal home computers in the future as well. It's likely that the continuing increases in storage capacity and drop in price per gigabyte will mean that it gets easier, not harder, to run Bitcoin on normal home computers.Quote There is also the potential for block chain compaction which will reduce the storage requirements for a fully-functional home computer Bitcoin. And there goes your storage. *poff* I wonder where you want to go with this. First introduce junk in blocks to make Bitcoins to heavy to use for other than large serverfarms, and then get rid of it.Title: Re: Version 0.3.18 Post by: ribuck on December 10, 2010, 01:09:16 PM ... introduce junk in blocks ... If it's useful to the sender, the recipient, and the miner, then it's not junk. Title: Re: Version 0.3.18 Post by: ShadowOfHarbringer on December 10, 2010, 04:41:39 PM ... introduce junk in blocks ... If it's useful to the sender, the recipient, and the miner, then it's not junk. Bitcoin is supposed to be currency by definition. Anything in it that is not directly currency-related can be classified as "junk". Perhaps separate protocols can be created for sending additional information based on private/public keys that already exist in bitcoin. Title: Re: Version 0.3.18 Post by: davout on December 10, 2010, 04:44:39 PM ... introduce junk in blocks ... If it's useful to the sender, the recipient, and the miner, then it's not junk. Bitcoin is supposed to be currency by definition. Anything in it that is not directly currency-related can be classified as "junk". Perhaps separate protocols can be created for sending additional information based on private/public keys that already exist in bitcoin. Bitcoin is supposed to be what users say its supposed to be. Title: Re: Version 0.3.18 Post by: wumpus on December 10, 2010, 06:17:15 PM Let's adhere to the KISS principle and keep it at simply a digital currency. It's already confusing enough for new users without bringing the kitchen sink in, and it could affect security. You can fork the chain if you want to store alternative information.
Title: Re: Version 0.3.18 Post by: davout on December 10, 2010, 08:57:30 PM as long as the fundamental properties of bitcoin remain there could be a lady gaga sextape encoded in the blockchain, i wouldn't care
Title: Re: Version 0.3.18 Post by: jgarzik on December 10, 2010, 09:04:43 PM as long as the fundamental properties of bitcoin remain there could be a lady gaga sextape encoded in the blockchain, i wouldn't care The Lady Gaga sextape would impose additional costs on you and everyone else, at least if you were trying to send currency while another was pushing the sextape data into the block chain. Then there's the new user slowdown, while each new bitcoin user downloads their copy of Lady Gaga. Title: Re: Version 0.3.18 Post by: ribuck on December 10, 2010, 09:05:29 PM ... it could affect security ... Let's not spread FUD. A text payload followed by OP_DROP is absolutely secure. Quote It's already confusing enough for new users without bringing the kitchen sink in A new user running the standard bitcoin App won't see anything different from what they see now. Title: Re: Version 0.3.18 Post by: davout on December 10, 2010, 09:07:38 PM as long as the fundamental properties of bitcoin remain there could be a lady gaga sextape encoded in the blockchain, i wouldn't care The Lady Gaga sextape would impose additional costs on you and everyone else, at least if you were trying to send currency while another was pushing the sextape data into the block chain. Then there's the new user slowdown, while each new bitcoin user downloads their copy of Lady Gaga. I hope the initial blockchain download is not going to remain as inefficient as it is today :) Title: Re: Version 0.3.18 Post by: MoonShadow on December 10, 2010, 09:45:19 PM Bitcoin is supposed to be what users say its supposed to be. Well, this user says that Bitcoin should remain a single tool, namely a cryptocurrency. And if I lose the vote I'll no longer be a user, so I suppose that in the end it would all work out. Title: Re: Version 0.3.18 Post by: MoonShadow on December 10, 2010, 09:48:54 PM I hope the initial blockchain download is not going to remain as inefficient as it is today :) Define "inefficient" in this context. My understanding is that the p2p network isn't inefficient for it's purpose, just not particularly well suited to bootstrapping new clients. An alternative way of bootstrapping a new client would help to limit the new user load upon the network in the future, but that's not the problem today. The delays in bootstrapping a new client today are largely due to the massive amount of checking that the client does while downloading the blockchain. Title: Re: Version 0.3.18 Post by: davout on December 10, 2010, 10:03:01 PM I hope the initial blockchain download is not going to remain as inefficient as it is today :) Define "inefficient" in this context. My understanding is that the p2p network isn't inefficient for it's purpose, just not particularly well suited to bootstrapping new clients. An alternative way of bootstrapping a new client would help to limit the new user load upon the network in the future, but that's not the problem today. The delays in bootstrapping a new client today are largely due to the massive amount of checking that the client does while downloading the blockchain. That's what would qualify as "inefficient" in my view. Well, actually, when i say not efficient, what i mean is that i run the client on a fat linux box and this one is fine. *but* i also run a windows client at office, and each time it downloads a significant amount of blocks my hardrive sounds like it is going to burst in flames any minute. Code: david@bankbox:~$ du -sh .bitcoin/ 124M .bitcoin/ This should not take 10 minutes to download on a reasonably optimized P2P network, not much longer. Bitcoin's network is probably not optimized for that, maybe we should think about using the bittorrent network to distribute fat chunks of the chain. On windows the harddrive sound is reaaally annoying, my colleagues even get curious as to wtf I'm doing with my computer :) Might be the debug.log flushes or the block chain, I honestly have no idea, but what matters is the result, isn't it ? Also it's a very frequently asked question : "when will my faucet coins show up ?" so it could be interesting to investigate. Title: Re: Version 0.3.18 Post by: jgarzik on December 10, 2010, 10:45:37 PM Define "inefficient" in this context. My understanding is that the p2p network isn't inefficient for it's purpose, just not particularly well suited to bootstrapping new clients. An alternative way of bootstrapping a new client would help to limit the new user load upon the network in the future, but that's not the problem today. The delays in bootstrapping a new client today are largely due to the massive amount of checking that the client does while downloading the blockchain. bitcoin's initial block download is far too dependent on the initial peer selection at the beginning of the download. I've gotten unlucky several times, with a peer that was achingly slow, or a peer that simply stopped sending blocks (one peer out there seems stuck at 82000 blocks for months). In the latter case, it took bitcoin over 30 minutes before download resumed. Disk and CPU were completely idle during that time. bitcoin could stand to take a page from bittorrent: compete among multiple peers, to see which one gives you the best download speed. If there is a network delay longer than 5 seconds, try another peer. Accidentally downloading the same block from multiple peers, during or after a network hiccup, does not harm bitcoin. It just wastes a bit of bandwidth. Title: Re: Version 0.3.18 Post by: sturle on December 10, 2010, 11:25:46 PM ... introduce junk in blocks ... If it's useful to the sender, the recipient, and the miner, then it's not junk. Bitcoin is supposed to be currency by definition. Anything in it that is not directly currency-related can be classified as "junk". Perhaps separate protocols can be created for sending additional information based on private/public keys that already exist in bitcoin. Those who want other services integrated with Bitcoins, just make an ad hoc protocol with it's own chain. Let the people who store information there pay with bitcoins rewarded to those who create new blocks, or something. Just don't push it everyone who just want to pay for stuff on the net. It should be possible to run a Bitcoin client on a smartphone or tablet without downloading Wikileaks, porn, Gaga videos, spam, ads, warez, all of usenet, and whatnot at the same time. Please! Title: Re: Version 0.3.18 Post by: theymos on December 11, 2010, 12:00:52 AM For those who wish to remove the restriction on inclusion and relaying of non-standard transactions, here is a patch on 0.3.18 to do so:
http://pastebin.com/raw.php?i=Z0DVga74 It does these things: - IsStandard is not checked when including transactions or relaying them. - An older, similar restriction on transactions with an unusual size or number of scriptSig OPs is also removed. - Non-standard transactions become ineligible for free space. You will not accept non-standard transactions if they don't include at least a fee of 0.01. You will relay such transactions, however. Generators that apply this patch will potentially receive more fees. However, I doubt anyone will actually produce any non-standard transactions for a while. You are still Bitcoin-compliant by applying this patch. You will not end up on a separate network (unless Bitcoin is changed to make these restrictions network-enforced). Edit: Modified version for SVN 200: http://pastebin.com/raw.php?i=6aQiEJDz Title: Re: Version 0.3.18 Post by: jgarzik on December 11, 2010, 12:14:51 AM You are still Bitcoin-compliant by applying this patch. This patch creates a new, non-mainline network ruleset. The "compliant" claim is somewhat specious. Title: Re: Version 0.3.18 Post by: ShadowOfHarbringer on December 12, 2010, 09:12:00 AM as long as the fundamental properties of bitcoin remain there could be a lady gaga sextape encoded in the blockchain, i wouldn't care I would. I want a currency, and i don't want to download somebody's lady gaga because of somebody wanted to put it in the chain. Just think what you are saying. Is this supposed to be a currency or what ? Junkyard ? ---- BTW I hate Lady Gaga. Title: Re: Version 0.3.18 Post by: ShadowOfHarbringer on December 12, 2010, 09:14:22 AM You are still Bitcoin-compliant by applying this patch. This patch creates a new, non-mainline network ruleset. The "compliant" claim is somewhat specious. Depends on what you call "mainline" and what you call "bitcoin". If "mainline client" = what satoshi proposes, because most of users trust his vision, then mainline it is. Title: Re: Version 0.3.18 Post by: jimbobway on December 15, 2010, 05:52:10 AM I also support a third transaction type for timestamp hash sized arbitrary data. There's no point not having one since you can already do it anyway. It would tell nodes they don't need to bother to index it. Yes it is possible already. But it is disappointing to encourage main bitcoin chain to be used for generic data storage. When a large amount of users are non-currency data users, currency users will face longer delays, higher costs, and decreased ability to send free transactions. Currency users will be discouraged by these factors from using bitcoin. All these folks talking about the glory of the free market conveniently omit that there only one, monopolized market right now -- the mainline chain. This implies decreased competition versus many markets (==many chains) and tragedy of the commons, as everybody shoves all their data onto the main chain. An alternate chain that encourages data storage would better serve data users, leaving the main chain to better serve currency users. Concerning using bitcoins as timestamps... Right now gold can be mined and used as a currency. You can also you gold to make jewelry, build circuit boards, etc., because it has special properties. Therefore, gold has more than one purpose which increases its value. As of now most people believe that bitcoin can only be used as a currency. If people start using bitcoins to timestamp their work, then every bitcoin actually has more intrinsic value because it has more than one purpose! A bitcoin is actually not only useful as a currency but it has the ability to timestamp. If someone could use this special bitcoin property similarly to how scientists used the conductive properties of gold, then bitcoins could takeoff in a different tangent which could further increase its value. Is there a breakthough application waiting to be discovered using the timestamp property out there??? Title: Re: Version 0.3.18 Post by: FreeMoney on December 15, 2010, 12:12:00 PM Concerning using bitcoins as timestamps... Right now gold can be mined and used as a currency. You can also you gold to make jewelry, build circuit boards, etc., because it has special properties. Therefore, gold has more than one purpose which increases its value. As of now most people believe that bitcoin can only be used as a currency. If people start using bitcoins to timestamp their work, then every bitcoin actually has more intrinsic value because it has more than one purpose! A bitcoin is actually not only useful as a currency but it has the ability to timestamp. If someone could use this special bitcoin property similarly to how scientists used the conductive properties of gold, then bitcoins could takeoff in a different tangent which could further increase its value. Is there a breakthough application waiting to be discovered using the timestamp property out there??? That makes sense Jimbob. I don't understand well enough to know what it makes sense to pay to be put in the chain so I don't know what will be in the chain in the long run, but whatever people are willing to pay the most for is what it will be. If registering domains ends up being the best use of this system I'll be confused and disappointed though. Title: Re: Version 0.3.18 Post by: casascius on December 15, 2010, 06:14:32 PM I'm relatively new and find this whole network intriguing. I come from a software development background. My outside opinion might not mean much, here it is for what it's worth.
I think Bitcoin should be just for currency. The whole idea of using it for DNS or for other purposes sounds like an abuse. If the distributed database concept brought to light by Bitcoin is viable for a DNS system, then great - may it be started as a completely independent blockchain and network. I don't see how marrying the two systems adds any value. If when I came across Bitcoin I had also discovered it did "DNS", I'd have been turned off by that. There is already enough new territory for the average newcomer to conquer, let alone one with no idea how software worked. Imagine the New York Stock Exchange also traded tampons and framing nails. That's how the idea of Bitcoin DNS looks to me. If I understand correctly, one of the core tenets of blocks is that they be prunable to the absolute minimum size (which I understand to be 80 bytes) to hold the "proof of work" hashes necessary to establish which chain is the longest. The idea of using them as permanent storage for convenience betrays this. I do think there should be a spot for arbitrary data to be sent along with transactions, but I think it should be VERY limited - and by that, I mean no more than either 32 bytes, meant as a sender's transaction reference. 32 bytes should be enough to fit a short URL, or at most, a 256-bit hash. I know somebody gained infamy for thinking 640Kbytes should be good enough for "anybody", but this isn't the same. I think it's fair to say that 2^256 possible references should be enough for anybody - Bitcoin should not offer payloads of any kind other than bitcoins! Besides, we expect Bitcoin users to have Internet access after all. Bitcoin users already have the means to communicate all the data they need, by reference. My standard disclaimer is I'm welcome to being corrected if it appears I have misunderstood the system, as I feel I have a decent grasp but I'm still a newbie. Title: Re: Version 0.3.18 Post by: MoonShadow on December 15, 2010, 06:39:41 PM I do think there should be a spot for arbitrary data to be sent along with transactions, but I think it should be VERY limited - and by that, I mean no more than either 32 bytes, meant as a sender's transaction reference. 32 bytes should be enough to fit a short URL, or at most, a 256-bit hash. I know somebody gained infamy for thinking 640Kbytes should be good enough for "anybody", but this isn't the same. I think it's fair to say that 2^256 possible references should be enough for anybody - Bitcoin should not offer payloads of any kind other than bitcoins! I agree, as do many others. There is great risk in trying to adapt Bitcoin into some kind of multi-tool. Simple tools that can be used in conjunction is what made Unix great, and both Linux & the Internet great by proxy. Bitcoin should be a currency system, and leave the othe innovations to other tools. The argument that some have made that another blockchain would take generation from Bitcoin (or vise versa) is a false one. People will contribute to what is important to them. Neither distributed.net, nor any other of the prior distributed work projects, makes any attempt to compensate participants. If a p2p DNS is important, people will volunteer both clocktime and bitcoin donations to support it. Title: Re: Version 0.3.18 Post by: ShadowOfHarbringer on December 16, 2010, 10:38:23 AM I'm relatively new and find this whole network intriguing. I come from a software development background. My outside opinion might not mean much, here it is for what it's worth. I think Bitcoin should be just for currency. The whole idea of using it for DNS or for other purposes sounds like an abuse. If the distributed database concept brought to light by Bitcoin is viable for a DNS system, then great - may it be started as a completely independent blockchain and network. I don't see how marrying the two systems adds any value. If when I came across Bitcoin I had also discovered it did "DNS", I'd have been turned off by that. There is already enough new territory for the average newcomer to conquer, let alone one with no idea how software worked. Imagine the New York Stock Exchange also traded tampons and framing nails. That's how the idea of Bitcoin DNS looks to me. If I understand correctly, one of the core tenets of blocks is that they be prunable to the absolute minimum size (which I understand to be 80 bytes) to hold the "proof of work" hashes necessary to establish which chain is the longest. The idea of using them as permanent storage for convenience betrays this. I do think there should be a spot for arbitrary data to be sent along with transactions, but I think it should be VERY limited - and by that, I mean no more than either 32 bytes, meant as a sender's transaction reference. 32 bytes should be enough to fit a short URL, or at most, a 256-bit hash. I know somebody gained infamy for thinking 640Kbytes should be good enough for "anybody", but this isn't the same. I think it's fair to say that 2^256 possible references should be enough for anybody - Bitcoin should not offer payloads of any kind other than bitcoins! Besides, we expect Bitcoin users to have Internet access after all. Bitcoin users already have the means to communicate all the data they need, by reference. My standard disclaimer is I'm welcome to being corrected if it appears I have misunderstood the system, as I feel I have a decent grasp but I'm still a newbie. + 1, you have my full support. Title: Re: Version 0.3.18 Post by: The Madhatter on December 16, 2010, 10:46:46 AM I think Bitcoin should be just for currency. The whole idea of using it for DNS or for other purposes sounds like an abuse. *chomp* I agree. I recently upgraded the 30 nodes I control to 0.3.18 with verbatim IsStandard() code, just to prove my support. |