This "consensus" talk gives a bad feeling. Prices should be set by markets.
Agreed; that is the longer-term goal. This is a short-term fix. |
|
|
|
|
No, it is not possible, there is a rule against that.
|
|
|
|
|
Collusion to gain oversized-profits never succeeds in the long-term, unless there are artificial barriers to entry (like government regulations).
I won't worry until our governments decide to pass the Officially Licensed and Inspected Bitcoin Generating Devices Law.
|
|
|
|
|
Will all of the internationalization/translations from the wxBitcoin port straight over to qtBitcoin?
|
|
|
|
So, questions:
* Do you think a continuous decrease of the block reward is better?
* Is it worth breaking backward compatibility for?
No and no, in my opinion. I think being able to explain the block reward as "starts at 50 every 10 minutes and is cut in half every 4 years" is a big advantage. I like simple-- "the simplest possible solution that will work" is a good engineering rule of thumb. |
|
|
|
I know I'm not using an actual argument in this post. Feels strange to do that, too. But I think it's safe to say that a solid consensus should not produce this outcome. There is no consensus. There is no generally accepted operating model for Bitcoin after minting becomes negligible. We better find one.
Why? Thats years and years away. I don't think any of us can predict exactly what is going to happen 10 or 15 or 20 years from now; I don't think it is possible to get a consensus now because there has never been a system like bitcoin before, so predicting how merchants, miners, and users will interact in 10 years seems to me to be impossible. So: do you think this supposed problem will happen all at once? Or will it happen slowly over time? If you think it will happen all at once, would there be any warning signs? If it is a problem that we can clearly see coming, then there will be time to react. I'm much more worried on the problems I see coming in the next year or two or three-- bitcoin-specific viruses and trojans, poorly coded bitcoin web services, and maybe bitcoin service operators getting charged with financial crimes that they didn't know they were violating. |
|
|
|
This has got me thinking. When transactions occur the coins get "broken up" if needed to make the payment with some change sent back to you. Wouldn't that mean that slowly the coins will get broken up smaller and smaller with time causing the kb for the transaction to go up, making the data required for transactions to slowly go up?
They tend to get put back together when you send larger payments. The algorithm that the current bitcoin client uses isn't the best possible algorithm for deciding when to combine or split coins; ideally, it would have some notion of how big your average transaction would be, and when sending coins it might split change or combine extra coins to make change that is about that big (so the next time you make a transaction there are old, previous, high-priority transactions it can use). If you ask nicely, I bet tcatm or somebody else will create a little web service that could tell you how long you have to wait for a 0.10 (or whatever) coin to mature before you can send it without a fee. |
|
|
|
|
Wednesday May 25'th bitcoin lunch in la Défense is on my calendar.
|
|
|
|
|
The networking code is the same in either case, so it was almost certainly just a coincidence and you got unlucky with the peers you connected to running -server from the command line.
|
|
|
|
|
The rules that the GUI (and bitcoind sends) follows to figure out if you should pay a fee are now the same as the rules in the block generation code. The rules themselves didn't change.
|
|
|
|
Clearly the fee system is suboptimal if one can reduce fees by workarounds that increase system overhead.
I learned long ago that it is much better to create a sub-optimal system that is simple and robust than to try to create a perfectly optimal system. Pretty darn good, with the right incentives in place to drive the long-term desired behavior, is good enough for me right now. I think "we" have been pretty good at responding fairly quickly to problems as they appear. I'm keeping a close eye on the free-transaction backlog, but I think tcatm's recent changes to http://bitcoincharts.com/bitcoin/ , showing transaction priority, and the recent change to the bitcoin client, so the default fee rules are the same for miners, relaying across the network, and the client, are working nicely. |
|
|
|
|
If your 0.33 bitcoins came from one or two recent payments to you, then waiting a day or three to let the inputs "mature" will let you send them without a fee. The transaction priority fee rules are designed to discourage people from sending lots of small bitcoin transactions in a short time.
If your 0.33 bitcoins came from 20 or 30 penny-sized payments to you, then you'll have to go to a lot of work to send them without a fee, because a 20- or 30-input transaction will be too big to qualify to be free. The transaction size fee rules are designed to discourage people from wasting everybody's disk and network bandwidth by sending big transactions.
If you did receive lots of tiny payments, you can try to bundle them up in chunks-- you might be able to send three payments of 0.10 BTC without a fee (because each of them would be smaller than the "too big to be free" size).
But you should ask yourself: is it really worth your time? 0.01 BTC is less than 5 US cents. If it takes you more than 20 seconds to send 2 or 3 payments to avoid the 0.01BTC fee, then you're valuing your time at less than US minimum wage.
|
|
|
|
BTW, can someone explain in layman words where from priority is defined?
Priority is a function of how many bitcoins are involved in the transaction (more is higher priority), the size (in bytes) of the transaction (smaller is higher priority), and the age of the transaction's previous transactions (older is higher priority). Your transaction is taking a long time because it involved only 0.14 BTC which you got from a transaction that happened earlier today. If you were running bitcoin version 0.3.21, it would have required that you add a 0.01BTC fee to send it. |
|
|
|
This has been lingering for months, and got bogged down in discussions of some nifty new mega-efficient binary protocol for stuff. That hasn't happened. So: https://github.com/bitcoin/bitcoin/pull/198This adds these new RPC commands: monitortx/monitorblocks: POST JSON-RPC to a URL when new wallet transactions or blocks are received. listmonitored: list URLS that will be POSTed to getblock: get information about a block, given depth in main chain. monitortx posts the same information you get from gettransaction. monitorblock/getblock posts: {
"hash" : "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048",
"blockcount" : 1,
"version" : 1,
"merkleroot" : "0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098",
"time" : 1231469665,
"nonce" : 2573394689,
"difficulty" : 1.00000000,
"tx" : [
"0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098"
],
"hashprevious" : "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
"hashnext" : "000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd"
}
|
|
|
|
|
No, the send-from address is not available, for a couple of reasons:
1) When people using a shared wallet service like MyBitcoin or MtGox send payments the "from address" could belong to any of the other users of the service (or could be a "change" address that doesn't belong to anybody). It is a bad idea to think that "address == person".
2) If more complicated transaction types are ever "turned on" in bitcoin, there might be more than one "from address". Satoshi designed-in support for complicated transactions like "this payment can only be spent if 2 of these 3 keys sign the transaction". In that case, there would be two "from addresses".
If you need this to refund coins, you'll need to ask the customer for a refund address.
|
|
|
|
If you want each receiving address treated as its own account, you can: setaccount <address> <address> ... and then use <address> as the name of the account. And validateaddress will tell you what account is associated with an address. |
|
|
|
Hence, I propose that instead of talking in bitcents we encourage the use of millicoins, microcoins, and nanocoins. That way the entire system relies on a single three-order grouping.
+1 |
|
|
|
|
I'll brain-dump my second half-baked idea of the day:
github has a nice API for basically everything it does (issues getting closed,etc).
I've been working on an API for ClearCoin (creating escrow accounts, etc).
Marrying the two might work nicely. Coders could publish their bitcoin addresses in their github profiles.
Bounties could be established for bugs (or, grumble, features) by creating a ClearCoin account, linking it to the issue (maybe by posting a machine-readable comment via the github api).
And when the issue was closed via a commit the bounty could be automagically paid to the coder(s) who contributed to the commit. (somehow... via a yet-to-be-written way for ClearCoin to get a where-to-release-coins address that is not set in advance).
Reasons not to do it: allegations of corruption/favoritism if people doing the pulling have to decide between two pull requests. Maybe less cooperation to find/fix things if people are competing for bounties.
|
|
|
|
|
Show Posts
