You are still Bitcoin-compliant by applying this patch.
This patch creates a new, non-mainline network ruleset. The "compliant" claim is somewhat specious. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
bitcoin itself is artificial scarcity.
|
|
|
|
Satoshi, are you endorsing the idea that additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?
It might be coins, but it doesn't have to be. Your reward could be a portion of namespace, ie. the domains themselves. The possibilities are endless. Bitcoin rewards you, essentially, with a piece of [digital] property. |
|
|
|
[22:11:50] <gavinandresen> MT`AwAy: RE: curl and ssl: I bet you have: rpcssl=true in your bitcoin.conf
[22:12:26] <gavinandresen> (correct syntax is rcpssl=1, I made the command/option file parsing consistent in 0.3.18)
Indeed, replacing rpcssl=true to rpcssl=1 fixed the issue.
Someone should update GetBoolArg() to accept 'false', 'true', 'yes' and 'no'. |
|
|
|
But.... "legally speaking".... or "tos speaking".... Is Bitcoin REALLY considered a "currency" by Google Checkout and/or Amazon? That seems like a good question to ask them. It bet they'd consider it "virtual merchandise".
The Bitcoin Store was turned down, after a Google Checkout review. |
|
|
|
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. |
|
|
|
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. |
|
|
|
Just wondering about the following example :
I broadcast a transaction, sending X coins to some address.
Doesn't get included in blocks for a while because I don't include a fee.
Do I have a way to cancel it and broadcast it again with a fee this time ?
See the discussion of locktime for transaction replacement. |
|
|
|
|
I think there is general agreement that arbitrary data (a comment field) should be an optional component of transactions.
The main point of contention now is whether or not to put that in the main block chain.
I think 32-64 bytes is sufficient for most uses -- reference id's and hashes. Custom block chains might want much larger limits: 512 bytes? 4k?
|
|
|
|
|
Arguments of "block sizes will get bigger anyway" miss the point.
If the total block size (and thus total fees) is higher for currency + data than currency alone (as is obvious), then the total network is that much more expensive for each transaction for currency+data than currency-only. Adding users to the bitcoin chain adds value and CPU power -- but each user must pay more for that service.
Thus, assuming the same currency transactions rate, a currency+data chain will always have higher fees than a currency-only chain.
Adding a new application data stream (BitDNS) to the mainline block chain taxes everyone, not just the users of the new app. The miners and the block chain benefit from this, but existing app users (bitcoin currency) suffer a bit.
This creates a natural tension that incentivizes creation of new block chains, when popular ones simply become too expensive due to large number of application users. It is interesting to ponder how an application may move from one block chain to another, while retaining value.
|
|
|
|
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. |
|
|
|
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'... |
|
|
|
A bunch of the current debate about including BitDNS or BitX makes assumptions that miners will include transactions or not based on some rather fine-grained conditions, while none of the standard code includes any sort of implementation that allows non-programmers to make decisions like that. How will I, the user, figure out what sort of fees have to go into a transaction?
For currency transactions, if you notice your transactions taking a long time to confirm, you increase the TX fee. For non-currency transactions, it sounds like there will be some sort of fee schedule. The software that generates these special, non-currency transactions would likely have a user-friendly interface to indicate the cost. |
|
|
|
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. 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. |
|
|
|
I directly emailed echelon, and he gives a different bitcoin address than "Max Stirner" at the top of the thread: I2P does accept bitcoin on 1JHJYGshG8Ds9XXHbXuTrDkf8XAXzNhi5c for the
I2P project.
Due to some other jobs I did not updated the webpage yet. Will be done
this weekend.
eche|on
|
|
|
|
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. |
|
|
|
If a past transaction becomes invalid and disappears, the website cannot avoid potential loss, because the user has already received their PayPal-USD or LR-USD or Pecunix GAU and disappeared. That's not always the case. Sometimes the customer will have a balance at the website. The operator of the website will certainly want to know if a past transactions becomes invalid and disappears. Sure, and that's easy enough to track with transactions. |
|
|
|
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. |
|
|
|
|
Show Posts
