|
No, it's from the karma mod. It was always listed on profiles.
|
|
|
|
|
You're probably isolated from the rest of the network and connecting to yourself repeatedly.
|
|
|
|
|
It's disabled, so everyone's respect is 0.
|
|
|
|
As to the idea that forum.bitcoin.org is not an official forum, sorry but that's naive.
Why? What makes anything on bitcoin.org official? No code is hosted here, and the bitcoin.org resources are not controlled by anyone currently involved in development. There are no links to bitcoin.org in the Bitcoin software. I think they're already in place anyhow, but I don't moderate the marketplace forum for thread hijacking much.
Off-topic posts should already be deleted or split in any section. It's hard to notice off-topic posts when you're reading dozens of threads at a time, though. More reports are needed. |
|
|
|
|
Create a competing forum. bitcoin.org should not be considered any more official than weusecoins.com or any other site.
|
|
|
|
|
There needs to be consensus in the Italian community about what subforums to create (if any). I don't think any are necessary, but I'll create them if a topic about it is created in the Italian section and several regulars reach an agreement.
|
|
|
|
what is an SCI pmt?
MyBitcoin has a shopping cart interface (SCI) that some sites use to handle Bitcoin payments. |
|
|
|
Oh, I see. Blocks that don't follow size-based fee rules would be rejected by other miners.
That could be done, but I'm not in favor of rejecting blocks based on fee rules (and that's not what I meant in my reply). Both fee reduction based on "old transaction deletability" and fee increase based on new transaction size can be optional. I am speculating on what miners will do later as a free-market response to problems. I'm not proposing that any changes like these be made now, and certainly not in a way that would become permanent. |
|
|
|
So why would miners promote (by reduced fees) transaction that save storage space instead of smaller transactions?
I feel I'm missing something in your point.
Say that there are three transactions of 200 bytes with one spent output and one unspent output each. If someone spends all three of those unspent outputs in inputs in a 300 byte transaction, then the network has saved 300 bytes. I think miners will like this behavior enough to give a small fee reduction. Size-based fee rules would also promote this behavior somewhat. |
|
|
|
|
Ah, I know what happened. You changed your display name, but this does not change your username. Your username was still MrEko. I changed it to "Sedo".
You may have received an automated password reset email when I changed your username, but just use the password I emailed you before.
|
|
|
|
|
There were useful replies, so I will just lock it.
|
|
|
|
Why would the "winner miner" apply that fee reduction?
He can get the whole fee while enjoying the saving in storage caused by the transaction.
Promoting smaller transactions is good for the miner unless he plans to quit mining soon. |
|
|
|
|
You actually could do true demurrage as a backward-compatible change. At least 50% of the mining power would need to agree to follow the same rules, but all other clients would have their transactions restricted by these rules regardless of whether they update. The miners could, for example, agree that all outputs must have their spendable value reduced by x BTC per retarget. Any transaction that violates this rule would never be accepted, just as if it was invalid. Furthermore, an output reduced to a sub-zero value could be safely forgotten by the network, since any spend using it would be invalid.
If miners with your rules don't have >50% of the network, you can't safely forget unspent transactions. If you are unable to find the transaction when it is needed for verification, you have only two bad choices:
- You can accept the transaction without checking it after it gets in a block. Every time one of these blocks ends up getting rejected by the majority of the network due to its invalid transaction, you will lose all of your hashing work since the last block. (This is even worse if you wait a few blocks before accepting it.)
- You can reject the transaction. Some important part of the network might accept the transaction, and you will be isolated from them unless you have more than 50% of the network.
I don't think fee-based demurrage will happen. Why would miners disincentivize people from allowing old transactions to be forgotten? Maybe spending old transactions will actually give you a fee reduction. More likely, you'll be charged an extra fee for turning a small transaction into a large transaction. You'll get a fee reduction for spending the last output of a transaction and turning a large transaction into a smaller one.
The strict demurrage I described at the beginning of this reply could happen if old transactions become a large burden, though I wouldn't like it. Hopefully other methods will be found.
|
|
|
|
|
Bitcoin Block Explorer also got a big spike in traffic starting on the 16th. 2,599 unique non-bot IPs on the 15th -> 7,832 unique non-bot IPs on the 16th. BBE is now serving ~400,000 pages per day (mostly from bots and sites like BitcoinCharts).
|
|
|
|
|
I get similar numbers using BBE data. 391288 transactions and 124638004 bytes over 126191 blocks.
|
|
|
|
|
Check your email.
I've had to reset passwords a few times lately. I wonder if there's a bug somewhere.
|
|
|
|
|
I sent an email to the address registered with your "Sedo" account.
|
|
|
|
|
Show Posts
