Peter Todd
Legendary
Offline
Activity: 1120
Merit: 1152
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2013, 07:38:26 PM |
|
I think Gavin has alluded to possibly rewarding those who run full nodes, which I think is the way to go. I don't see any reason why miners should get rewarded, yet those who run full nodes and eat the bandwidth/disk space get nothing.
I replied in the main forum: https://bitcointalk.org/index.php?topic=197169.0
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2013, 07:54:11 PM |
|
Going from that, a DHT is quite a step down, quite a bit less secure. DHTs are vulnerable to hot spots -- where the whole world queries just a few nodes -- and sybil attacks[1]. On sybil attacks, bitcoin's current peer finding mechanism does a better job of intentionally spreading itself widely across networks; a DHT tends to concentrate on a few nodes. It becomes much easier to attack a portion of the blockchain, if it were stored as (hash,block) key-value pairs as commonly suggested. If an attacker may DoS even a single (hash,block) pair, you prevent the entire world from downloading or verifying the entire bitcoin blockchain, because the chain is thus broken. The time spent looking up each hash across a worldwide DHT would be quite slow; that is the equivalent of downloading 234,831 different torrents, not one big torrent. Storage via DHT is a fun toy idea, but it's stupid, slow and insecure as a primary method. Massive replication is far more secure and decentralized. You should look into Freenet's datastore. They have managed to implement a secure, distributed, redundant content-addressed filesystem that avoids most of those pitfalls. It's resistant to attack by malicious nodes and maintains good data persistence even though storage nodes come and go randomly. Right now the Freenet datastore is several orders of magnitude larger than the blockchain. Their network is slow because it's being careful to anonymize who is inserting and requesting data, but you could get the other benefits at a much better performance with those constraints removed.
|
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2013, 08:20:50 PM |
|
Using the chain as data storage, rather than currency, costs everybody, because it increases the rate at which people are discouraged from running full nodes. It increases the costs of that dataset that cannot be pruned, and must be carried for eternity: the unspent transaction output set (UTXO), the list of coins available for spending.
Just a quick intermediate question interrupting this interesting discussion: I've been using the blockchain for a "proof of existance at point x in time" using the hash of a scan of a casascius coin as private key to generate a bitcoin address. I sent 1 satoshi to that address. Is that to be considered "misuse of the blockchain"? If that satoshi is spent (which can be done because the private key has been published) the "data" is "prunable", right?
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
Blowfeld
Newbie
Offline
Activity: 53
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2013, 10:06:49 PM Last edit: May 06, 2013, 10:39:47 PM by Blowfeld |
|
As much as I dislike SD's (and other's) abuse of the blockchain, this is a bad idea. First, any idea that is admitted to be "temporary" should be suspected of being a bad idea. Second, IMHO, it is philosophically wrong -- at best a band-aid for a bigger problem that needs a different solution. Third, it's debatable whether or not this change will alter the behavior of those (ab)using the blockchain. The motivation of gamblers is different. I don't see how it will have any impact on them, other than to change the "dust" amount from 1 unit to 5430 units. Those storing data in the blockchain will just move data around in units of 5430 Satoshi, rather than disposing of units of 1 Satoshi. But fourth, I fear the technical issues have not been fully considered, and that's my main objection to this scheme...
One technical problem noted somewhere in this thread is how do you deal with change that's under the limit. If you are a "bitcoin millionaire", it's probably not much of a problem. If you are just starting out, it might be a significant problem. Say you have 0.01005429 BTC to your name. One rule says you can't spend less than 0.01. This new rule says you can't spend between 0.01000000 and 0.01005428. (I haven't looked at the code. Does the client fail? Are you forced to overpay the recipient? Are you forced to pay your change as part of your "fee"?)
If you overpay the recipient, I suspect there are some automated systems that either (1) won't accept the payment or (2) might attempt to send your change back. You are requiring modification to any such automated system that now exists. You are also requiring modification to every other standard bitcoin client (else some transactions that used to go through will not go through). And you are requiring potential modification to every application that generates its own transactions. This proposed modification has consequences far beyond the official Satoshi client, and as far as I can tell, there has been no general solicitation of comments.
Similarly, what if you have one account with just slightly more funds than needed for a transaction. Does the client automatically choose a second account to make sure the change is at least 5430 Satoshis? I thought one of the goals of the client was to avoid mixing payment sources as much as possible to maintain some "privacy". Although this shouldn't happen often, if you are dealing with random amounts between a bitcent or two, it seems this would occur about 1 in 300 such transactions. (Again, not a problem for "bitcoin millionaires", but a potential problem for those just starting out.)
Another technical problem noted (but dismissed as irrelevant by some developers) is the increased window for double-spends. Deny it if you want, but when each mining pool (and each full node) can choose parameters to decide whether or not a transaction is to be relayed, I think the surface area for double-spends has increased significantly.
Related to the above is the question of a node's "banscore". I haven't examined the code. If node B receives a transaction from node A, which node B thinks is non-standard, does node B bump node A's banscore? I won't speculate on the implications until I look at the code, because this might be a red herring.
Finally, in many respects, you are trying to achieve results similar to that of a "5430 to 1 reverse stock split". Of course, I'm not actually proposing this! But some of the things corporations and stock exchanges go through when handling a reverse stock split might be considered in handling this proposed change. Do you want to consider making every transaction output a multiple of 5430 Satoshis? If it were a more round number, such as 5000 Satoshis, this might actually make sense. For your very small "stockholders", the way I see it, you are changing the value of very small balances from "economically unspendable" to "practically unspendable". To avoid a perceived hit in public confidence, the Bitcoin Foundation should send up to 5429 Satoshis to every address now containing 1 Satoshi of "dust". (Or whatever amount is necessary to bring every address up to the minimum spendable amount.)
|
|
|
|
jdbtracker
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2013, 11:18:31 PM Last edit: May 08, 2013, 12:46:01 AM by jdbtracker |
|
When that runs out, the system can support transaction fees if needed. It's based on open market competition, and there will probably always be nodes willing to process transactions for free. Satoshi Nakamoto I'm going to thank the Developers for implementing this change, It definitely saved me having to recompile it myself. I hope other people notice that too. Now I can simply update my bitcoin.conf file with mintxfee command. kudos now I can control what I allow my miners to process, I do intend to make a living doing this, so I can adjust my fees according to where I live; Though I do think it was a little cheeky to create this much controversy, but now a whole swath of people are a little more informed and the dialogue has started. Here is how much 0.00005430 BTC is in USD: .0065 dollars... that's half a cent. and for.. 0.632 Yen 0.0065 CAD 0.124 Lempiras 63.18 Rupiah 0.26 Pesos As you can see being able to change this fee is very useful, depending on what part of the world you are in, setting limits creates a regional mining community; It also increases transaction speed by limiting number of relays it has to go through... very important, there are 17 major worldwide relay centres that monitor all traffic on the internet... avoiding them is key. As for the Data being put into the block chain, very sneaky ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) but definitely if you are using Bitcoin for that, https://freenetproject.org/ should work a lot better, or use TOR. The blockchain solution is great, it can be used for all sorts of things, time to startup a new project, the power of the CypherPunk movement is limitless. Need to do a search under TOR use YaCy http://yacy.net/en/index.html your own personal search engine. I am new to Bitcoin, but as far as I understand the changes, if you want to upgrade go ahead, no one is forcing you to, just keep running the old client. I like being able to change the limit of the transaction fees, so I will be making mine go to 1 centavo Lempira, I was born in Honduras so, that will be my limit. .000005 bitcoin minimum for me personally. If you do have a problem with this new re-compile of bitcoin, set the MIN_TX_FEE to .00000001 That way you can still reap the benefits of Satoshi Dice, who doesn't want to make some cash off those transactions fees? ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) The better solution will be thought up later, for now, we just got to educate and get people to run FreeNets blockchain instead of using Bitcoins; Trust me it is way more secure. I just found this: http://www.youtube.com/watch?v=K2OBbK-7qPcAmazing! so many people working on Bitcoin. I'm quite shocked to see how much work Satoshi did, worked all alone for so long, holy $h*+!
|
If you think my efforts are worth something; I'll keep on keeping on. I don't believe in IQ, only in Determination.
|
|
|
soundasleep
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2013, 11:57:24 PM |
|
The more people who run a full node, the greater the decentralization[1][2].
I can't run a full node full time right now because there is no upload throttling. The Bitcoin client slows my Internet down to literally unusable (4sec+ pings). Not because of hard drive space. I've got 900 GB free right now.
|
|
|
|
countryfree
Legendary
Offline
Activity: 3066
Merit: 1047
Your country may be your worst enemy
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 12:18:54 AM |
|
There's a lot of theory here. I've never done any transaction of less than 1 cent, and I don't think I will ever. Faucets? Websites that give free money? They're all doomed. Can anyone seriously believe they will keep on giving money forever? When we will have reached the 21 millions limit, nobody will give out satoshis anymore.
That make gambling sites the ones with the most to lose here, but I'm sure they can adapt. Right now, in Las Vegas, you can't play less than a dollar.
|
I used to be a citizen and a taxpayer. Those days are long gone.
|
|
|
gmaxwell
Staff
Legendary
Offline
Activity: 4242
Merit: 8662
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 12:25:04 AM Last edit: May 07, 2013, 12:42:11 AM by gmaxwell |
|
There's a lot of theory here. I've never done any transaction of less than 1 cent, and I don't think I will ever. [...] That make gambling sites the ones with the most to lose here, but I'm sure they can adapt. Right now, in Las Vegas, you can't play less than a dollar.
No such sites exist, they all have minimum plays larger than the value in question— no one has identified any actual currency usage believed to be affected by this. The outputs impacted this generally cost more to redeem than they're worth... so there is basically no sane reason to create them except to add load to the system. you are changing the value of very small balances from "economically unspendable" to "practically unspendable". To avoid a perceived hit in public confidence, the Bitcoin Foundation should send up to 5429 Satoshis to every address now containing 1 Satoshi of "dust". (Or whatever amount is necessary to bring every address up to the minimum spendable amount.)
The bitcoin system doesn't have "accounts" every individual payment to you is totally separate as far as the system is concerned. If txout value of X is economically unspendable (meaning it costs you more in fees marginally then it returns) then it's still economically unspendable no matter what other coins you have. You can think of them as coins with negative value: spending it makes you poorer because adding it to your transaction increases that transaction's fees by more than the value of Bitcoin it returns. Giving you _more_ negative value coins doesn't help you productively spend your initial negative value coin. The dust change doesn't change what you can spend— it just changes what outputs you can create— no more freaky costs more-to-spend-than-you-get-outputs, unless you can get cooperation from a miner or mine them yourself. For people who have less than that amount in total— well, they were already unable to spend them: transactions without any output value of less than 0.01 that doesn't pay a fee of at least 0.0005 BTC is has been non-standard for a long time (and previously required a 0.01 fee). I can't run a full node full time right now because there is no upload throttling. The Bitcoin client slows my Internet down to literally unusable (4sec+ pings).
If you disable listening (listen=0 in the bitcoin.conf) that works around that pretty much entirely. That is not a replacement for additional flexibility in the long term, but it's really easily done. Things like adjusting client traffic can be twiddled over time, but unspendable data storage outputs are forever. As an aside— you might want to google bufferbloat, as it sounds like your local network could use some tuning.
|
|
|
|
hl5460
Legendary
Offline
Activity: 1620
Merit: 1000
news.8btc.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 05:28:07 AM |
|
I think it is fair enough to block this.
|
|
|
|
astutiumRob
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 06:35:24 AM |
|
The Achilles Heel of Bitcoin is being swamped by transactions worth less than a cent because, unlike fiat coinage transactions, Bitcoin transactions are stored on thousands of servers for years or forever.
The storing of the entire "ledger" is one of the main problem with bitcoin, and really can only be solved by shifting to a time-based-balances summary. The reason it takes bitcoin "users" 4 days to get started is the collection, unpack and interpretation of the blockchain. Having a full chain only at "miners" as part of the "cost" to maintain the network (and profit from it through mining) is fine, but for global adoption, the client needs to become lightweight and portable - so so "balances as at last sync to the network" and "transaction since" is one solution - for those who *want* the whole lot (for whatever reason) should always be able to get it, but most people dont (and I can see "trusted nodes" for mobile apps becoming more prevalent over time) Another "needed" feature is a solution to the "empty pocket" problem - having multiple addresses for receipt of bitcoins and then consolidating them and *abandoning* those addresses. In the "real" world you dont pay fees to take money from your multiple moneyboxes and spend them in one go - from a ledger (and therefore bitcoin) point of view they're logically transferred to one "Box" and then spent from there Is the current change a good idea - IMHO as a temporary measure while proper solutions to the issues of bitcoin growing are found, then yes. Is the amount being suggested (5430 satoshis) right - probably not - as it will discourage small miners from pools where they're not submitting lots of shares, so get small "payouts" - which ultimately hurts the network not helps it.
|
|
|
|
radiumsoup
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 01:27:10 PM |
|
The storing of the entire "ledger" is one of the main problem with bitcoin, and really can only be solved by shifting to a time-based-balances summary.
The reason it takes bitcoin "users" 4 days to get started is the collection, unpack and interpretation of the blockchain.
Assuming by "users" you mean end users and not miners, Electrum has already started working on that, actually. Users creating a wallet do not need to download the blockchain to use their wallet. (Android support is super clunky so far, but it's a pretty neat solution to that issue.) Pruning resolved blocks is also a good suggestion, but the optimal solution is still going to be enforced minimum transaction fees. http://electrum.org/
|
PGP fingerprint: 0x85beeabd110803b93d408b502d39b8875b282f86
|
|
|
yaffare
Newbie
Offline
Activity: 45
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 03:25:56 PM |
|
You should make this a rule, not optional. Otherwise its way too confusing.
Nobody knows if he can send a micro-micro payment or not.
Also I think this is not censorship. Its just another rule. You guys know that bitcoin is currently limited to 500.000 transactions per day. Its far away from being ready for world-currency. So for now we should focus on important transactions. In the future when bitcoin is ready, we can add micro-micro payments.
|
|
|
|
boonies4u
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2013, 08:59:26 PM |
|
You should make this a rule, not optional. Otherwise its way too confusing.
Nobody knows if he can send a micro-micro payment or not.
Also I think this is not censorship. Its just another rule. You guys know that bitcoin is currently limited to 500.000 transactions per day. Its far away from being ready for world-currency. So for now we should focus on important transactions. In the future when bitcoin is ready, we can add micro-micro payments.
I think at this time that determining default behavior is more than enough. Making this a rule would make an unnecessary limit on what transactions miners can confirm and nodes can relay.
|
|
|
|
CanadianGuy
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2013, 02:06:01 AM |
|
You should make this a rule, not optional. Otherwise its way too confusing.
Nobody knows if he can send a micro-micro payment or not.
Also I think this is not censorship. Its just another rule. You guys know that bitcoin is currently limited to 500.000 transactions per day. Its far away from being ready for world-currency. So for now we should focus on important transactions. In the future when bitcoin is ready, we can add micro-micro payments.
can this 500k/day limit ever be changed?
|
|
|
|
yaffare
Newbie
Offline
Activity: 45
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2013, 10:15:56 AM |
|
You should make this a rule, not optional. Otherwise its way too confusing.
Nobody knows if he can send a micro-micro payment or not.
Also I think this is not censorship. Its just another rule. You guys know that bitcoin is currently limited to 500.000 transactions per day. Its far away from being ready for world-currency. So for now we should focus on important transactions. In the future when bitcoin is ready, we can add micro-micro payments.
can this 500k/day limit ever be changed? sure, its the 1MB hardcoded block-size limit. but we cannot just increase this number. infrastructure for it has to be build first, you have to consider: - block propagation time - block-chain size - solution to serve a lot of light-weight clients and I guess theres much more stuff to improve in the code.
|
|
|
|
radiumsoup
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2013, 01:47:25 PM |
|
You should make this a rule, not optional. Otherwise its way too confusing.
Nobody knows if he can send a micro-micro payment or not.
Also I think this is not censorship. Its just another rule. You guys know that bitcoin is currently limited to 500.000 transactions per day. Its far away from being ready for world-currency. So for now we should focus on important transactions. In the future when bitcoin is ready, we can add micro-micro payments.
can this 500k/day limit ever be changed? sure, its the 1MB hardcoded block-size limit. but we cannot just increase this number. infrastructure for it has to be build first, you have to consider: - block propagation time - block-chain size - solution to serve a lot of light-weight clients and I guess theres much more stuff to improve in the code. the rate of block solving could change... 5 minute block solving times instead of 10 minute, for instance. (After all the bitcoins are mined, anyway, or else the reward would have to change as well)
|
PGP fingerprint: 0x85beeabd110803b93d408b502d39b8875b282f86
|
|
|
Shevek
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2013, 02:09:46 PM |
|
Bitcoin is not suitable for micro transactions. This is all. Nothing new here, it was pretty obvious from the very beginning that all those dusters are allowed to shit into blockchain only until there are not enough more serious transactions to fill the blocks.
It's a pity read this assert. The most useful thing of bitcoin is micropays. If you block them, bitcoin lose its main value and a new coin should enter the game.
|
Proposals for improving bitcoin are like asses: everybody has one 1SheveKuPHpzpLqSvPSavik9wnC51voBa
|
|
|
lophie
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2013, 02:31:54 PM |
|
the rate of block solving could change... 5 minute block solving times instead of 10 minute, for instance. (After all the bitcoins are mined, anyway, or else the reward would have to change as well)
No they cannot.
|
Will take me a while to climb up again, But where is a will, there is a way...
|
|
|
kjlimo
Legendary
Offline
Activity: 2114
Merit: 1031
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2013, 02:36:14 PM |
|
Bitcoin is not suitable for micro transactions. This is all. Nothing new here, it was pretty obvious from the very beginning that all those dusters are allowed to shit into blockchain only until there are not enough more serious transactions to fill the blocks.
It's a pity read this assert. The most useful thing of bitcoin is micropays. If you block them, bitcoin lose its main value and a new coin should enter the game. See my signature to get your hands on such coins... EDIT: PM me if you're interested in my alt coin newsletter which covers new coins as well as my buy/sell price points that have treated my cryptocurrency portfolio well!
|
|
|
|
radiumsoup
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2013, 03:26:55 PM |
|
the rate of block solving could change... 5 minute block solving times instead of 10 minute, for instance. (After all the bitcoins are mined, anyway, or else the reward would have to change as well)
No they cannot. Why not, exactly? It wouldn't be very hard to change the protocol rules to allow the difficulty to remain low enough to generate blocks on a 5-minute average (or 8 or whatever) instead of 10. I mean, I understand completely the whole "don't make blocks too fast or they'll be a bunch of orphans as competing blocks overlap" issue, but I don't know if there's any compelling evidence that it takes 5 entire minutes for a majority of nodes to verify a new block. (could be wrong, but I haven't seen any real world data to indicate there is.)
|
PGP fingerprint: 0x85beeabd110803b93d408b502d39b8875b282f86
|
|
|
|