Bitcoin Forum
May 09, 2016, 12:59:56 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 ... 114 »
201  Bitcoin / Bitcoin Discussion / Re: WARNING! Bitcoin will soon block small transaction outputs on: May 11, 2013, 06:43:49 PM
Who gets to decide how slow is too slow?
BTC Guild right now.
Okey dokey.

Have you contributed any patches to p2pool to make it more efficient / easier to install / etc? If not, why not if you're so worried about centralization?

(honest question, I don't keep up with p2pool development because I'm personally not terribly worried about mining centralization)
202  Bitcoin / Bitcoin Discussion / Re: WARNING! Bitcoin will soon block small transaction outputs on: May 10, 2013, 04:44:15 PM
The fact that usually it works because most of the outputs were recently created is incredibly dangerous. If the ratio of best case to worst case performance gets bad enough the attacker just has to come along with a block spending outputs that weren't recently created, or otherwise picked in a way where retrieval happens to be slow, to knock slower miners offline.

Who gets to decide how slow is too slow?

Mining these days requires investing in ASIC hardware. Solo mining or running a pool will very soon require investing in a reasonably fast network connection and a machine with at least a few gigabytes of memory.

Knocking the slowest N% of solo miners/pools off the network every year (where N is less than 20 or so) is not a crisis. That is the way free-market competition works.
203  Bitcoin / Development & Technical Discussion / 0.8.2rc1 ready for testing on: May 10, 2013, 03:41:52 PM
Bitcoin-Qt version 0.8.2 release candidate 1 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/test/

This is a maintenance release that fixes many bugs and includes
a few small new features.

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues


How to Upgrade

If you are running an older version, shut it down. Wait
until it has completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
/Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you are upgrading from version 0.7.2 or earlier, the first time you
run 0.8.2 your blockchain files will be re-indexed, which will take
anywhere from 30 minutes to several hours, depending on the speed of
your machine.

0.8.2 Release notes

Fee Policy changes

The default fee for low-priority transactions is lowered from 0.0005 BTC
(for each 1,000 bytes in the transaction; an average transaction is
about 500 bytes) to 0.0001 BTC.

Payments (transaction outputs) of 0.543 times the minimum relay fee
(0.00005430 BTC) are now considered 'non-standard', because storing them
costs the network more than they are worth and spending them will usually
cost their owner more in transaction fees than they are worth.

Non-standard transactions are not relayed across the network, are not included
in blocks by most miners, and will not show up in your wallet until they are
included in a block.

The default fee policy can be overridden using the -mintxfee and -minrelaytxfee
command-line options, but note that we intend to replace the hard-coded fees
with code that automatically calculates and suggests appropriate fees in the
0.9 release and note that if you set a fee policy significantly different from
the rest of the network your transactions may never confirm.

Bitcoin-Qt changes

* New icon and splash screen
* Improve reporting of synchronization process
* Remove hardcoded fee recommendations
* Improve metadata of executable on MacOSX and Windows
* Move export button to individual tabs instead of toolbar
* Add "send coins" command to context menu in address book
* Add "copy txid" command to copy transaction IDs from transaction overview
* Save & restore window size and position when showing & hiding window
* New translations: Arabic (ar), Bosnian (bs), Catalan (ca), Welsh (cy),
  Esperanto (eo), Interlingua (la), Latvian (lv) and many improvements
  to current translations

MacOSX:
* OSX support for click-to-pay (bitcoin:) links
* Fix GUI disappearing problem on MacOSX (issue #1522)

Linux/Unix:
* Copy addresses to middle-mouse-button clipboard


Command-line options

* -walletnotify will call a command on receiving transactions that affect the wallet.
* -alertnotify will call a command on receiving an alert from the network.
* -par now takes a negative number, to leave a certain amount of cores free.

JSON-RPC API changes

* listunspent now lists account and address infromation.
* getinfo now also returns the time adjustment estimated from your peers.
* getpeerinfo now returns bytessent, bytesrecv and syncnode.
* gettxoutsetinfo returns statistics about the unspent transaction output database.
* gettxout returns information about a specific unspent transaction output.


Networking changes

* Significant changes to the networking code, reducing latency and memory consumption.
* Avoid initial block download stalling.
* Remove IRC seeding support.
* Performance tweaks.
* Added testnet DNS seeds.

Wallet compatibility/rescuing

* Cases where wallets cannot be opened in another version/installation should be reduced.
* -salvagewallet now works for encrypted wallets.


Thanks to everybody who contributed to the 0.8.2 release!

APerson241
Andrew Poelstra
Calvin Owens
Chuck LeDuc Díaz
Colin Dean
David Griffith
David Serrano
Eric Lombrozo
Gavin Andresen
Gregory Maxwell
Jeff Garzik
Jonas Schnelli
Larry Gilbert
Luke Dashjr
Matt Corallo
Michael Ford
Mike Hearn
Patrick Brown
Peter Todd
Philip Kaufmann
Pieter Wuille
Richard Schwab
Roman Mindalev
Scott Howard
Tariq Bashir
Wladimir J. van der Laan
freewil
gladoscc
kjj2
mb300sd
204  Bitcoin / Development & Technical Discussion / Re: Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch on: May 10, 2013, 04:10:20 AM
Security in this context is being inappropriately treated like a binary concept.


+1
205  Bitcoin / Development & Technical Discussion / Re: Initial replace-by-fee implementation is now available on testnet on: May 09, 2013, 07:19:55 PM
I think this is a terrible idea.

If it was "higher fee with superset of outputs of first spend" then that'd be fine.

Zero-confirmation transactions will never be safe because of potential Finney attacks. But we don't need (and, in my opinion, shouldn't) make them less safe by encouraging anti-social behavior via default mining policy.
206  Bitcoin / Legal / Re: Fincen Requirements? on: May 06, 2013, 03:54:45 AM
If you have to ask...
... hire a lawyer.
207  Economy / Service Discussion / Re: How will 0.8.2 affect S.Dice? on: May 06, 2013, 02:12:41 AM
Multiple Dr. Evil type of characters including Gavin Andresen (Notice Mr.Anderson) have been tinkering in their underground facility thinking of new ways to destroy the free economy along with their CIA friends as the camera zooms out of the darkness you can only hear their evil laughing as they summon this patch from the deepest dungeons of hell to completely censor any micro transactions or "dust" in hopes of probing the masses for compliance before further arbitrary, dictatorship-style changes take place.

Nah, I'm not in the underground facility any more. I packed up the hookers and blow and we're all living the sweet life in a penthouse suite now.
208  Bitcoin / Bitcoin Discussion / Re: WARNING! Bitcoin will soon block small transaction outputs on: May 06, 2013, 02:02:39 AM
You idiots know it's just a default setting that can be changed, right?

You can just change this in the config, and connect to a few nodes in pools that accept non-standard tx's.
+1

Knock yourselves out, no fork needed, just add this to your bitcoin.conf and convince a few big miners or mining pools to do the same:

    minrelaytxfee=0

209  Alternate cryptocurrencies / Altcoin Discussion / Re: More Genesis Block Discussion on: May 05, 2013, 04:31:40 PM
lightenup gave me this advice for generating a genesis block:

Awww, that is cheating!

You really have no business creating your own block chain if you don't understand the code well enough to figure out how to mine a new genesis block without somebody else's help.
210  Bitcoin / Development & Technical Discussion / Re: btcd: a bitcoind alternative written in Go on: May 03, 2013, 11:31:28 PM
10-4, i'll have the guys put together a list of things that may need updating.

Ummm... it is a wiki.  They should just update it themselves (after asking questions if they have any), it is much more efficient.
211  Bitcoin / Development & Technical Discussion / Re: btcd: a bitcoind alternative written in Go on: May 02, 2013, 05:25:58 PM
our devs have implemented the protocol per the docs at https://en.bitcoin.it/wiki/Protocol_specification . additionally, they have been reading bitcoind code as necessary to make everything work. there are a couple scenarios where bitcoind does not behave according to the published spec. we are currently quirking around this but we can document it if you think it helpful.

Yes, please, feedback from re-implementors is very helpful.


212  Bitcoin / Development & Technical Discussion / Re: What ownership proof does Bitcoin client send to network when spending coins? on: May 01, 2013, 02:24:46 AM
So I'm guessing a 3rd option happens, it sends my BitcoinAddress, plus some other derived number that lets the network know that my client has my private key, but it doesn't actually send my private key.    Is that right?

Yes.

If you want to get geeky about it, it sends an ECDSA signature derived from the private key and the transaction data, and the full public key that corresponds to your bitcoin address (the address is a shorter version of it).
213  Bitcoin / Development & Technical Discussion / Re: Entropy during private key generation on: May 01, 2013, 02:13:28 AM
... In any given distro, there are thousands of packages, so thousands of upstream projects, and tens to hundreds of package maintainers.

Shouldn't we be worried about this?

Sure. That's one of the reasons why I'm reluctant to upgrade the distro/dependencies for the deterministic build process, and generally prefer to use older dependencies rather than the "latest and greatest" of everything. But there's a tradeoff between "risk that an Evil Maintainer slipped something in" and "risk that we ship with an upatched bug" -- e.g. we tend to be on the latest version of OpenSSL, but a few releases behind of Qt4.

PS: if you really want to be completely paranoid, you should only run bitcoin on old hardware/OS manufactured before 2009 so you can be sure the  hardware/firmware/OS doesn't have any wallet-stealing circuits/code lurking....
214  Bitcoin / Development & Technical Discussion / Re: Treat dust outputs as non-standard, un-hardcode TX_FEE constants on: April 30, 2013, 06:51:14 PM
RE: NODE_RELAYCOST :

I'm generally against any "take my word for it" settings.  What would stop somebody Up To No Good from setting NODE_RELAYCOST and then lying about what they will relay?  Miners might decide to try to increase fees by Sybil-attacking the network and lying about NODE_RELAYCOST....
215  Bitcoin / Development & Technical Discussion / Re: Treat dust outputs as non-standard, un-hardcode TX_FEE constants on: April 30, 2013, 06:48:07 PM
It also adds a minimum transaction output "magic number".  That is an additional rule.  It doesn't exist at the moment right ?

Minimum transaction output is (conservatively) calculated from the minimum relay fee setting.  It did exist before, it was just set to '1 satoshi'.

We made 0-satoshi outputs non-standard a couple of releases ago, but consensus is that was a mistake-- 1-satoshi is not the right number, because the marginal cost of spending a 1-satoshi output is greater than its value.

Again, eventually it might be economical to spend 1-satoshi outputs. When it is, the minimum relay fee will be on the order of a satoshi or two, and this code will do the right thing.
216  Economy / Service Discussion / Re: Bitcoin Foundation says my computer is infected? on: April 30, 2013, 03:30:04 PM
Bitcoin Foundation uses CloudFlare to protect bitcoinfoundation.org from distributed denial of service attacks.

As the message says, either your computer or a computer on the same network / ISP as yours was sending lots of spammy requests to CloudFlare. So they ask you to solve a CAPTCHA to prove that you're not part of the bad guy's botnet.

217  Bitcoin / Development & Technical Discussion / Re: Poor man's/de facto transaction replacement on: April 30, 2013, 02:13:26 PM
A transaction is final if:

All of its sequence numbers are INT_MAX
  OR
lockTime has passed.

I'm still of the opinion that non-final transactions shouldn't be broadcast over the p2p network; I think the parties negotiating using them should keep them to themselves until they are final, and broadcast then.
218  Bitcoin / Development & Technical Discussion / Re: Treat dust outputs as non-standard, un-hardcode TX_FEE constants on: April 30, 2013, 02:03:57 PM
Y'all read the pull request, yes?

So: if you have a better suggestion for fixing the problem of new users wasting lots of time gathering tiny drips and drabs of bitcoins, and then getting upset when they can't spend them (because it costs more in fees that they are worth), I'm open to suggestions.

RE: "what about when bitcoins are worth a million dollars apiece"

Umm, that's what the "un-hardcode TX_FEE constants" part is all about?

RE: trolling about Foundation setting the fee:

Go back under your rock, please. This pull request is the first step towards a market between miners (who want higher fees) and merchants/users (who want lower fees, but also want their transactions confirmed). Miners can already control what fees they accept, this pull lets users control (very clumsily, improvements on the road map) the fee they are willing to pay.
219  Bitcoin / Bitcoin Discussion / Re: Bitcoin Blocksize Problem Video on: April 30, 2013, 01:57:59 PM
Network bandwidth is growing too, although probably not as fast.  So this is still a realistic concern.

Network bandwidth is currently growing about 20% per year, or roughly doubling every four years.

Satoshi's original code had a 32MB block size limit, which he dropped to 1MB as part of a bunch of band-aid fixes to make denial-of-service attacks harder.

RE: density of full nodes:  In my opinion, if it is affordable to run a full node (less than, say, $100 per month in server costs-- that is a trivial monthly cost for most businesses and some individuals) then we'll continue to see tens of thousands of full nodes.

Median cost of a dedicated server with lots of bandwidth, disk and CPU is under $100/month these days, which would support a block size at least ten times the current maximum.

And all of THAT is before even starting to think about possible optimizations (e.g. figure out how to mitigate the "insert malicious data" problem-- maybe Peter Todd's security bonds would be helpful-- and a shared DHT storing all valid transactions combined with bloom filters on connections could make it cheap for any one machine to be a fully validating node).

Please, don't listen to all of the FUD being thrown around about raising the block size even before there is any solid proposal for what should be done.

220  Bitcoin / Bitcoin Discussion / Re: Bitcoin Blocksize Problem Video on: April 28, 2013, 05:37:30 PM
My reaction:  stop spreading FUD.

"small mining pools will go out of business" -- give me a break! My back-of-the-envelope calculations say that anybody willing to spend a few hundred dollars a year on a dedicated server with a high-bandwidth connection can support a MUCH, MUCH larger block size.

The block size will be raised. Your video will just make a lot of people worried about nothing, in exactly the same way Luke-Jr's BIP17 proposal last year (and his hyperbolic rhetoric about BIP16) did nothing but cause a tempest in a teapot.
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 ... 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!