#mtgox topic since yesterday : Mt.Gox 24/7 IRC support channel | don t ask to ask, just ask | offtopic goes to ##mtgox-chat | tickers and trades on #mtgox-RT and #bitcoin-RT | LTC support coming this month Duplicate post. Scroll up and read the thread before posting
|
|
|
"If there ever is a way of breaking up a Bitcoin into smaller fractions..." I guess one ten billionth isn't tiny enough for some people Already replied to author with corrections
|
|
|
Nothing stops a pool from running a subscription-only bitcoind instance via which users can submit any transaction they want directly.
Certainly. Eligius will send non-standard transactions that include a certain set-by-Eligius fee. Because non-standard transactions are not relayed, you must submit such transactions directly to Eligius. I wish more miners would offer services like this.
|
|
|
It is obscene that minimum tx fees are fixed BTC/KiB recommendations. This must be determined by individual miners! Miners must decide for themselves how much tx fees they accept. Miners need to be competing with each other on this. That was the original idea of Bitcoin. This will solve the problems of variable Bitcoin exchange prices by itself! Miners can already do this. Most of them just haven't chosen to do so yet. Yes and no. Miners select which transactions appear in a block... but clients choose which transactions to relay to other peers. Most clients will not even relay spam transactions (for obvious reasons... they are spam).
|
|
|
In light of the rapid increase in value of BTC in other currencies, we’re gonna have to look at the fees and how to scale up the network to deal with smaller transactions. Right now, the standard 0.0005 BTC fee is about $0.05. It’s not that big of a deal yet, but it makes sending anything less than a dollar (0.01 BTC) somewhat expensive. And that’s before accounting for higher transaction volume
It is widely agreed that the default fees need to be adjusted. However, standard disclaimer: bitcoin is not, and never will be, a micro-payment or micro-transaction network. Perhaps the solution can also be a de-centralized sub-network that works similarly as BTC that deal with smaller transactions and only charge the standard fee when pulling out?
Yes, this is called "off-chain transactions" and it is a very good, very realistic solution. No matter how much bitcoins scale up, there will always a market for micro-payments and micro-transactions. It is predicted that micro-payment services, bots and networks will appear to handle this use case.
|
|
|
Wouldn't it be even better to stop using fees as anti-DoS? Why can't we detect DoS by simply measuring the amount of data a peer is sending? If it goes beyond X KB/s, we stop storing and relaying transactions coming from this peer, eventually we disconnect from it and temporarily ban its IP locally. X could be configurable, in case there's a strong need to change the defaults without a release.
Because we are a decentralized network You can instead connect to 20,000 peers, and send one tiny spam through each. Requiring some minimal cost to send a transaction, even if 1 satoshi, is a very elegant solution to spam. However, as many others have noted, having a fixed fee schedule is too rigid, too inflexible.
|
|
|
It sounds like forrestv is instead in favor of alternate means to extend the effective work interval through merging of parallel chains. Various theoretical designs were discussed.
We may end up making a fork or a frankenbuild of p2pool to fix things for testing. I don't see why in the end it would need to fork for everyone, but it would be a hard fork and everyone would need to upgrade to a version where everyone is on the same share chain.
It ultimately seems like 10 seconds is just too short, given Internet propagation, current Avalon hashrate, and the up to 1.5-second delay it can take for work to be returned from Avalons (high latency). Thus, I argue for around 30 seconds, which would imply a hard fork at some point.
|
|
|
Can someone explain me how block v2 is an improvement?
Prevents duplicate transaction id's from being creating, and assists in block verification, by putting block height into the special "coinbase" transaction #0 found in every block. See BIP 34: https://en.bitcoin.it/wiki/BIP_0034
|
|
|
Yes I think you've found the "problem" The issue is, the asics NEED a higher difficulty, or they are going to kill the smaller miners in p2pool.
Yes, this was established the day the first Avalon arrived I also think as difficulty greatly increases, we are going to need a longer long-poll time as well. maybe 20 or 30 seconds.
On IRC, an ASIC-only p2pool share chain idea was floated, with a higher difficulty by default and a longer time between shares.
|
|
|
UDP is an example of the tremendous misalignment of incentives between "core dev" and commercial use.
UDP has the potential to deliver blocks and transactions more rapidly throughout the network. The former benefits miners, and the latter benefits all bitcoin users.
|
|
|
Idea: why not increase the hash difficulty for larger blocks? So if a miner wants to pass the 1MB threshold, require an extra zero bit on the hash. There's a big disincentive to include lots of tx dust.
Hmm, so a block with twice the difficulty can have twice the size? In effect, this allows the block rate increase faster than once every 10 minutes, by combining multiple headers into a single header. If you have 1MB of transactions worth 10BTC and another 1MB worth 5BTC (since they have lower tx fees), then it isn't worth combining them. A double difficulty block would give you 50% the odds of winning, but you only win 15BTC if you win. That actually effectively illustrates part of the difficulty in creating a solution: our economic reasoning will be clouded for many years by the block subsidy, which will probably dwarf the transaction fees for years to come. Efficiencies which must exist in the self-supporting, fee-only future are unseen at this time.
|
|
|
In general it sounds like an unworkable scheme. There is definitely no consensus on the block size issue at all.
|
|
|
Given renewed interest, it is strongly tempting to jump in and fix the major misfeatures: - getwork proxying (should be getblocktemplate for high speeds)
- internal work generation
- stratum protocol support
- separate database threads
|
|
|
Seems to me Bitcoin's biggest problem at the moment is that there is only one implementation.
Incorrect. There are several implementations. It seems that there is absolutely no desire by the core dev team to ever have more than one client,
Incorrect. Gavin actively encourages alternative implementations, and I've written two alternate implementations. At least one was linked earlier in this thread.
|
|
|
I can see that, yes. However in my case I certainly wasn't CPU bound, and I certainly wasn't network bound. I can only conclude I was bound by the rate at which the 5 or 8 nodes I was connected to were willing to pass me the blocks.
Most likely you are bound by the poor peer selection. Initial blockchain download occurs from one peer at a time. If that peer is slow, then your entire blockchain download is slow. Yes, it's stupid and yes it needs fixing (patches welcome). The blockchain torrent is a stopgap fix, that works around the find-a-good-peer issue.
|
|
|
Read the byline. It's from CNBC.
|
|
|
Why is this thread locked ? https://bitcointalk.org/index.php?topic=113400.1180I think Bitcoin Foundation needs a PR person. Developers in general suck at PR, they're to narrow minded and too tech focused to understand the needs of ordinary users and the ordinary public. (This is no attack on the devs, which are doing an excellent job - it's just a realization of how reality is, and what we should do) I don't think it's an attack.... I happen to agree completely.
|
|
|
Website visits spiked up by more than an order of magnitude due to some online articles.. and a also single comment on a Slashdot article about FBI spying. I had to take my BM address off of the homepage because I was getting a message about every 2 minutes.. mostly in Russian.
Better get multiple streams working. And maybe a test network...
|
|
|
Does anyone even know if registering with fincen is even that much of a hassle? There are no fees or anything. Do you even need to collect info for smaller transactions?
There are no fees at the federal level, but you must have a "compliance officer" (who is not you) and many other rules that, if skipped, can land you in jail.
|
|
|
|