Bitcoin Forum
May 09, 2016, 01:00:11 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 ... 114 »
241  Bitcoin / Development & Technical Discussion / Re: Funding of network security with infinite block sizes on: April 06, 2013, 06:49:31 PM
So the longer I think about the block size issue, the more I'm reminded of this Hayek quote:

Quote
The curious task of economics is to demonstrate to men how little they really know about what they imagine they can design.

F.A. Hayek, The Fatal Conceit

We can speculate all we want about what is going to happen in the future, but we don't really know.

So, what should we do if we don't know? My default answer is "do the simplest thing that could possibly work, but make sure there is a Plan B just in case it doesn't work."

In the case of the block size debate, what is the simplest thing that just might possibly work?

That's easy!  Eliminate the block size limit as a network rule entirely, and trust that miners and merchants and users will reject blocks that are "obviously too big." Where what is "obviously too big" will change over time as technology changes.

What is Plan B if just trusting miners/merchants/users to do the right thing doesn't work?

Big-picture it is easy:  Schedule a soft-fork that imposes some network-rule-upper-limit, with whatever formula seems right to correct whatever problem crops up.
Small-picture: hard to see what the "right" formula would be, but I think it will be much easier to define after we run into some actual practical problem rather than guessing where problems might crop up.


242  Bitcoin / Development & Technical Discussion / Re: To Fee or not to Fee on: April 05, 2013, 08:50:25 PM
I think there doesn't have to be One True Answer, and I'd like to see the different clients experiment with different ways of estimating fees.

I like your idea, Jan-- go for it!

I want Consumer Reports magazine to do an article in 15 years comparing bitcoin wallets and figuring out which one gives the fastest transactions for the lowest fees...
243  Bitcoin / Bitcoin Discussion / Re: Fundamental fee / security issue in bitcoins future? on: April 05, 2013, 02:47:29 AM
From these premise I draw the conclusion that the amount of hashing power in the system (premise #3) will directly correlate with the amount of transactional fee’s in the system (premise #1), and hence the security of the system (premise #2).

You're assuming that miners are completely distinct from the people who want the network to be secure (users/merchants/exchanges/etc).

That is a bad assumption. Nothing stops a merchant who wants more network security from either subsidizing miners (maybe in exchange for a promise to prioritize transactions to them) or mining themselves.

This is already happening, not for reasons of security but for other reasons.
244  Bitcoin / Development & Technical Discussion / Re: The minimum transfer fee is not trivial anymore on: April 02, 2013, 05:13:51 PM
Quote
There is one more change I'd like to make that is independent; re-define "dust" based on the floating transaction fee (e.g. a dust output is any output with a value of less than 1/4 the minimum fee-per-kb required to get into one of the next 6 blocks).  And make any transactions with dust outputs non-standard, so they're not included in the memory pool or relayed.

Why not applying the same logic you described above? (they only get dropped if they can't fit in your memory pool)

Because dust outputs are more trouble than they're worth. They bloat wallets, cost more in fees to spend than they're worth (unless you go to ridiculous lengths to spend them), and are abused as a side-channel-in-the-blockchain-communication-mechanism.

If I could go back in time, I would go back and try to convince Satoshi to make them non-standard to begin with....
245  Bitcoin / Development & Technical Discussion / Re: The minimum transfer fee is not trivial anymore on: April 02, 2013, 02:58:32 PM
Here's the thumbnail sketch on the code that I think needs to be written to handle fees properly:

1). Memory-limit the memory pool-- the set of transactions waiting in memory eligible to be included in a block. Matt Corallo has been working on that.  The limit should be a small multiple of the median block size of the last few hundred blocks.

2) Use the same algorithm/parameters/etc for adding transactions to the memory pool that we use to fill blocks.

3) Only relay transactions that fit into your memory pool.  This is the DoS prevention, your transaction won't get relayed if your node doesn't think it will end up in a block soon.

4) Estimate minimum transaction fee / priority needed to get into a block, based one:
    a) At startup:  the transactions in the last few blocks
    b) If you've been running long enough to "warm up" your memory pool:  transactions in the memory pool

5) Expose the estimate in the GUI's "suggested transaction fee" dialog.

All of that will give a floating fee that will change based on how many transactions, at what priorities/fees, are currently waiting to get into blocks.

There is one more change I'd like to make that is independent; re-define "dust" based on the floating transaction fee (e.g. a dust output is any output with a value of less than 1/4 the minimum fee-per-kb required to get into one of the next 6 blocks).  And make any transactions with dust outputs non-standard, so they're not included in the memory pool or relayed.
246  Bitcoin / Bitcoin Discussion / Re: Are there security issues with Bitcoin for Free / Faucet-Services? on: March 31, 2013, 11:23:33 PM
The only security risk with free bitcoin services is that they'll remember your IP address and associate it with the millibitcoins that they give you.

If you're the conspiracy theory type, then here's one for you: a very good way for a Three Letter Agency to create a database that correlates bitcoin wallets to real people would be for them to run a free bitcoin service (along with whatever they're currently doing to correlate IP addresses with real people).

247  Bitcoin / Bitcoin Discussion / Re: Main developers don't give a damn about us, bitcoiners! on: March 31, 2013, 10:17:11 PM
r.willis is confused about the BIP process.

It is not "Write a specification. Submit a BIP.  Argue for a while, revise the specification.  Finalize BIP, then everybody agrees to implement it."

I know there are standardization processes that try to work that way, and they're generally miserable failures. You end up with bloated specifications and implementations that don't work with each other because everybody interprets the spec slightly differently.

I like the IETF model, of working code and rough consensus. So, once the payment protocol is implemented and early adopters have had a chance to play with it, it will become a formal BIP.  Until then, as Mike said, I'll be tweaking https://gist.github.com/gavinandresen/4120476 as I run into issues.
248  Bitcoin / Development & Technical Discussion / Re: Bitcoin-Qt 0.8.x MacOS X app menu on: March 31, 2013, 01:14:47 AM
I have been developing myself over the last 20 years on AmigaOS, MS-DOS, Windows NT, Linux, Mac OS X, iOS and Android platforms (in more or less that order...)

Nice!  We need a good Mac OSX developer, do you know C++?  Are you willing to learn Qt?

My main machine is a Mac, but I'm not an expert OSX developer (I spend all my time in a Terminal window in emacs, pretending my Mac is a Unix machine).
249  Bitcoin / Legal / Re: Conceptually, what could the government do to defeat bitcoin? on: March 30, 2013, 12:59:57 PM
Wiki is out of date. Everybody running their node as a tor hidden service would work just fine as of a couple of releases ago.
250  Bitcoin / Bitcoin Discussion / Re: Main developers don't give a damn about us, bitcoiners! on: March 29, 2013, 07:24:28 PM
As usual, Gavin descends upon us and then disappears mysteriously, again...

So... you complain about development not happening faster, and then you complain that I'm not spending all of my time here on the forums?

"okey dokey"
251  Bitcoin / Development & Technical Discussion / Re: 465k Transaction... on: March 29, 2013, 04:28:21 PM
Holy crap... they have $1000 in coins, and they spend $300 to send $700... yikes.

Transactions larger than 100K are non-standard now, so I doubt the big transaction was ever broadcast. Almost certainly the transaction belonged to the miner, and they paid the fees to themself.
252  Bitcoin / Bitcoin Discussion / Re: Lower the minimum Transfer fee?! (Currently 0,0005BTC) on: March 29, 2013, 04:22:27 PM
Hi, i was wondering if it is possible to lower the minimum transaction fee for bitcoin.

Sure.

First, you need to make sure miners will accept bitcoins with the lower fee.  So lobby your favorite miner or mining pool to set the -mintxfee=  parameter to something lower than the default 0.0005 BTC-per-kilobyte; you can ask them if they will increase the size of the blocks they're creating and include more free transactions, too (those are settings they control).

Then, if you're using Bitcoin-Qt, you can set the transaction fee in the Preferences/Options dialog.

Right now, network peers won't relay low-priority transactions that include a fee of less than 0.0001 BTC, so that is as low as you should go. Fixing that is near the top of the (long) TODO list, but I really want to fix it correctly so we developers get out of the business of deciding what the transaction fees should be, and instead let the network decide.

If you generate a small number of high-bitcoin-value transactions (e.g. you have more than 1 BTC in your wallet and make a few purchases a week) then you should probably leave the Pay transaction fee setting at zero; Bitcoin-Qt will send your transactions without a fee, which will be just fine.



253  Bitcoin / Bitcoin Discussion / Re: Main developers don't give a damn about us, bitcoiners! on: March 29, 2013, 03:12:14 PM
So....  move too fast and we maybe introduce a forking bug or a security vulnerability.

Move too slow and maybe we get fired-- somebody faster at incorporating safe changes releases their own fork.

For me, "move slow" is the right answer.

But I would be completely happy contributing patches to somebody else running a fork who solves the "move fast but be safe" problem.
254  Alternate cryptocurrencies / Altcoin Discussion / Re: What is the point of Litecoin if Bitcoin is THE cryptocurrency? on: March 28, 2013, 04:46:46 PM
Ummm.... speaking of the hardfork, has a version of Litecoin been released yet that fixes the problem?
If it's a rhetorical question, that's OK.

If not, I am worried.

Not rhetorical: it needs to be fixed, or your blockchain can easily be forked.

Beware of Altchains that are abandoned or neglected by their developers (activity at https://github.com/litecoin-project/litecoin/commits/master doesn't look healthy to me... and now y'all are going to accuse me of spreading FUD, so I'll go away and shut up).
255  Bitcoin / Bitcoin Discussion / Re: Upgrade bitcoin.org on: March 28, 2013, 12:56:05 PM
Bitcoin is not a single product any more, so a "Download Now!" button doesn't make sense any more.

Just like bittorrent or linux aren't single products. And if you visit bittorrent.org or linux.org... guess what?  No download button.
256  Alternate cryptocurrencies / Altcoin Discussion / Re: What is the point of Litecoin if Bitcoin is THE cryptocurrency? on: March 27, 2013, 08:14:20 PM
- It's always good to have an alternative. Remember the bitcoin hardfork recently? If Litecoin stays one version behind Bitcoin we will have Litecoin as a back up and Bitcoin as a test network.

Ummm.... speaking of the hardfork, has a version of Litecoin been released yet that fixes the problem?
257  Bitcoin / Development & Technical Discussion / Re: How to send BitCoins with LOW TX FEE (Not No TX Fee) on: March 23, 2013, 10:31:38 PM
Straight Bitcoin isn't designed for really small transactions.  If you're sending less than something like $1 worth of bitcoins, you should expect to pay 10% or more in fees. More if you're trying to send $0.10 or less.

There is no magic fairy wand we can wave and make Bitcoin suddenly great for gazillions of tiny transactions; plan your businesses accordingly. As transaction volume increases, there will be more competition for space in blocks and fees are likely to rise.

And please avoid filling your customer's wallets with "dust" that they'll pay huge fees to spend; a payout should be at least a couple of cents, not a fraction of a penny. I think there is pretty good consensus among the core developers that sooner or later we'll make "dust" outputs non-standard, so they are not relayed or mined by default (details to be worked out, we need to implement a good algorithm for auto-adjusting the definition of "dust").


258  Bitcoin / Bitcoin Discussion / Re: Bitcoin-Qt/bitcoind version 0.8.1 available on: March 23, 2013, 10:20:24 PM
If you're on Linux or Mac, run contrib/tidy_datadir.sh if you want to get rid of old, not-used-any-more files in your data directory.

It will safely remove the blkindex.dat and blk000?.dat files.

If somebody wants to write an equivalent .bat file that does the same on Windows, that'd be fantastic!  I don't know hardly nuthin about Windows batch files.

As deepceleron says, the blk000?.dat files are hardlinks, so even though it looks like they're taking up space they're not. And they're safe to delete (just don't delete anything in the blocks/ or chainstate/ folders).
259  Bitcoin / Mining / Re: Compensating miners on the wrong side of The Big Fork on: March 23, 2013, 01:50:33 PM
To be clear: the 'donor' was the EFF, and their only request was that the Bitcoins be given back to the bitcoin community. If you like, think of it as a bulk payment of transaction fees that the faucet would have paid if it had been operating over the last year instead of closed (due to lack of time for me to fight the scammers).

Because it sent tiny transaction amounts, it paid almost as much in fees as it gave out...
260  Alternate cryptocurrencies / Altcoin Discussion / Re: Strategy for new alt coins on: March 23, 2013, 01:37:58 PM
Somebody should exploit all the DoS bugs that have been fixed to put the dead altcoins out of their misery, starting with the BDB lock limit bug.

Because if they keep scraping along, the worst thing that could happen would be for them to suddenly get popular-- because then attackers WILL swoop in and cause chaos.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 ... 114 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!