Bitcoin Forum
May 09, 2016, 12:59:49 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 ... 114 »
181  Bitcoin / Bitcoin Discussion / Re: Ruh Roh, bitcoin on the radar of the IMF? on: June 05, 2013, 05:05:43 PM
Thoughts?

This gives me warm fuzzies; a University of Chicago professor speculating about how a wildly successful Bitcoin might affect the International Monetary Fund!

I don't really care what is said, just the fact that Bitcoin is being talked about in the elite Ivory Towers is a very good thing.

182  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 05:59:30 PM
Every point presented on this subject has already being addressed. Multiple times.

Yes.  If you're feeling helpful, please create a wiki page or other document that organizes all of the pro/con arguments: economic and technical. And maybe another wiki page that organizes all of the various proposals for how to increase the block size.

I've been derailed the last week by a death in the family, and still need to finish up some payment protocol work.
183  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 04, 2013, 02:46:47 PM
angry internet trolls like ShadowOfHarbringer and Gavin.

I'm doing well this month, so far I've been called an "Angry Internet Troll", a "coward", and a "nazi".

184  Economy / Computer hardware / WTS: BFL 5 GH/s ASIC miner on: June 04, 2013, 02:38:36 PM
Selling my Butterfly Labs BitForce 5 GH/s SC (aka Jalapeno) ASIC miner.

It has been reliably cranking out about 5 and a half GH/s at about 35 watts for
two weeks now; I'm selling it just so I have one less thing in my life to think about.

I paid 25.9 BTC for it; best offer over 26 BTC before 16:00 UTC Sunday, 9 June gets it.
I'll ship it UPS/USPS/Fedex on the 10'th or 11'th, you must pay shipping (e.g. if you
want it overnight, add shipping charges from Amherst, MA 01002 to your payment).

PGP signed version of the above, so you know this is really me and not a scammer who managed to hack my forum account:
Code:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Selling my Butterfly Labs BitForce 5 GH/s SC (aka Jalapeno) ASIC miner.

It has been reliably cranking out about 5 and a half GH/s at about 35 watts for
two weeks now; I'm selling it just so I have one less thing in my life to think about.

I paid 25.9 BTC for it; best offer over 26 BTC before 16:00 UTC Sunday, 9 June gets it.
I'll ship it UPS/USPS/Fedex on the 10'th or 11'th, you must pay shipping (e.g. if you
want it overnight, add shipping charges from Amherst, MA 01002 to your payment).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQIcBAEBCgAGBQJRrftpAAoJECnZ7msfxzDBeZQP/iver66p7TpihqndjdcCAlAr
e5ZYdOWtsB2xqosnodk+ikhZIqwq4qPrYlRg3BvanIzLsrM90EbvmPso7yaxKElA
Rezhg6gMEfTiFAQqin6mi5ZcUHjKngLXWfYBd7cByzCwgxN6UUdljFntbEpStteC
E2eA5rO+UTs2dZsxTu3yEployLPoA1Abv5nN7EcCYvQ/EVsGW3C9Zewb0Q5pE313
2ULIeHg55I3nBPcy9IrA4Hjumt743AmtCWYLeKlAQcKgR5Z+4MsCzOeJwvHN/QeX
uVhE0Mb4x49buoGN/bQwy//MZD1NqLJnzuBTsfgcC5Yp8Hfpvs+nUBYqXFMhYC35
okPx/RIJxbIGz8yFjj9rrSEbIbSs4aP4SHXZS4+Ku/mBxvx9yKzlVr5ef/bnzU3i
w0trdxkmADDEpaZREUKoi8EvDthC9k5XVViDLbINOO+MsndL4vwMbGC98OiBCudl
8Zb+YvG+ghiJQyemcgCsFkDIz6jP9lqo/yush8L5H0zZ29dVwiC/O1CfwFa4bv0H
TcyaaSycIvK4OuRXOFjWoybmlv2LWJmeK6d7JCchIsHpsCMQZlpVce5oAjicmpg9
o3fesjkwqDj8Yii8KTiqmEcWzVz3m3cycDtDyw6AaEnnpE+aJCe0jJBTO0l6YNB7
gOYmhDypG2VCqCbthBML
=GtFS
-----END PGP SIGNATURE-----
185  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 03, 2013, 08:18:20 PM
So you are OK with like 70% of the haspower going to a fork that did not accept your change?

No, absolutely not. The process for a hard fork looks like:

+ Get rough consensus that the change is necessary.
+ Write the code.
+ Get it reviewed and thoroughly tested.
+ Release software that will support it when X% of hashing power agrees

... where X is a super-majority (like 75% or more).  If 70% of hashing power disagrees, then it doesn't happen. Miners will express support by producing block.version=3 blocks (just like they are now producing block.version=2 blocks that MUST include the chain height in the coinbase transaction).

It is possible the X% threshold will never happen if 1MB is plenty big enough. It is possible it will only happen when transaction fees start going up and pressure increases on pools to make their blocks bigger (or maybe merchants tired of paying high fees figure out they'll save money by mining or operating pools themselves, will get X% of hashing power, and will increase the block size).

Again, I spent a lot of time at the conference talking with people about the block size issue, and there is definitely consensus that 1MB just won't be big enough eventually. That has nothing to do with microtransactions, normal growth in "macrotransactions" will bump up against the limit in a year or three.
186  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 03, 2013, 06:53:08 PM
And second, even if it did, there are bigger powers out there that you need to convince - how are you planing to do that, when obviously there already are people who are convincing them otherwise?

Which "bigger powers" and which "people" ?

Is there some secret cabal out there I don't know about?

If you mean "Peter Todd has convinced some big mining pool operators not to increase the size of the blocks they create" -- then great!  That's the free market at work, big mining pools should be free to create blocks that are as large or as small as they like, and to accept or reject other's blocks for whatever reason they like.

187  Bitcoin / Press / Re: 2013-06-01 Andresen returns 726 BTC to privacy organisation on: June 03, 2013, 04:47:24 PM
Thanks!

PS:  I'm still giving away 10 BTC per month from those funds to the Minecraft Faucet (I committed 100BTC to the Minecraft Faucet folks before the EFF announced they'd accept Bitcoin donations again)...
188  Bitcoin / Development & Technical Discussion / Re: Please do not change MAX_BLOCK_SIZE on: June 03, 2013, 04:44:10 PM
The block size will be raised, that is the overwhelming consensus among the people who are actually writing code and using Bitcoin for products and services that it needs to happen.

And there is a tiny minority of people who will loudly proclaim that isn't true and that the core developer are going to destroy Bitcoin if the block size is raised.

If you want to be helpful, please organize a list of objections to raising the block size limit and responses to those objections.

I believe the last objection raised was that a higher block size limit would make it impossible to mine anonymously, but I think that has been debunked with the notion of "read the firehose of transactions non-anonymously, then broadcast just new block header + coinbase + listof(truncated transaction hashes) anonymously."

I'll soon be writing up a plan for how we can safely raise the block size limit.


RE: central planning:

No central planning is why I would like to eliminate the hard, upper blocksize limit entirely, and let the network decide "how big is too big."

RE: "the plan"  :   The plan from the beginning was to support huge blocks.  The 1MB hard limit was always a temporary denial-of-service prevention measure.
189  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] eMulah (EMU) - NOT a BitCoin fork/clone - call for beta testers on: May 31, 2013, 12:16:13 AM
Currency generation is a collaborative effort between n-client nodes and a hatching node.  Each node in the system will cast a vote to a random hatching node to whether to create a currency unit (EMU).

How do you prevent Sybil attacks-- somebody creating a gazillion n-client and/or hatching nodes, and voting themselves lots and lots of new currency?

And how does a node choose a "random" node-- does every node know about every other node?  If yes, then how do you avoid getting O(N^2) communication as the number of nodes (N) rises and every existing node must be told about every new node?
190  Bitcoin / Development & Technical Discussion / Re: Computational bounty using output scripts? on: May 30, 2013, 05:38:19 PM
The problem is security and developers' unwillingness to accept more op codes (ie making them standard)

Security, yes (including potential for denial-of-service attacks of various sorts).

But demonstrate a spiffy, compelling use of new opcodes on testnet and we'll talk about making them standard.

191  Bitcoin / Development & Technical Discussion / Re: Zerocoin: Anonymous Distributed E-Cash from Bitcoin on: May 30, 2013, 01:15:54 PM
I've started and then stopped writing about Zerocoin three or four times now; my thoughts about it are still muddled.

It adds a whole lot of complexity to transaction creation/verification to solve one problem:  how to mix coins/transactions with zero trust in the mixing process.  That's technically nifty, but I wonder if it is the best engineering solution.

I wonder if just using a couple of semi-trusted mixers would be a lot faster/smaller/simpler.

And then I start thinking about "tainted coins" in general. If we imagine a world with either mandatory or voluntary "taint tracking" (I have no idea whether or not that will ever happen), then it seems to me any mixing scheme that isn't "always on" is likely to fail in practice-- all coins coming out of the mix will be considered tainted.

Why? I assume that most users (if you are reading this are NOT "most users") don't care much about privacy/anonymity. So I would assume most people would choose the lowest cost, fastest, most convenient method for their transactions. Anybody using a mixer will be either a weirdo, principled privacy nut (like us) or a criminal. I don't see other "privacy first" projects taking over the world, but do see lots of big, successful "quick and easy and free" projects.

Then my thoughts get muddled, because "it is hopeless, just give up" is not an answer I'm willing to accept. But it feels to me like finding an essentially zero-cost way to increase transaction privacy that everybody uses by default is the best answer. Making your network connection more private is the other piece of the puzzle, though, and all of the solutions for that (either route through a couple of semi-trusted proxies or use Tor or i2p) add significant convenience/speed/financial costs.
192  Bitcoin / Bitcoin Discussion / Bitcoin-Qt / bitcoind 0.8.2 (final) available on: May 29, 2013, 09:20:28 PM
Bitcoin-Qt version 0.8.2 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/

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

* fixed a getblocktemplate bug that caused excessive CPU creating blocks.
* 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.


Known Bugs

* Entering the 'getblocktemplate' or 'getwork' RPC commands into the Bitcoin-Qt debug
console will cause Bitcoin-Qt to crash. Run Bitcoin-Qt with the -server command-line
option to workaround.

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
Warren Togami
Wladimir J. van der Laan
freewil
gladoscc
kjj2
mb300sd
super3
193  Bitcoin / Development & Technical Discussion / Re: 0.8.2rc3 ready for testing on: May 27, 2013, 04:20:49 PM
latency of what? getblocktemplate?  getbalance?
194  Bitcoin / Development & Technical Discussion / 0.8.2rc3 ready for testing on: May 24, 2013, 11:05:07 PM
0.8.2 rc2 never made it out the door; two crash-on-shutdown bugs and a bitcoin.ico file that made the windows gitian build non-reproducible made us jump to rc3 instead.

So:

Bitcoin-Qt version 0.8.2 release candidate 3 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
--------------------

* fixed a getblocktemplate bug that caused excessive CPU creating blocks.
* 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
Warren Togami
Wladimir J. van der Laan
freewil
gladoscc
kjj2
mb300sd
super3
195  Bitcoin / Bitcoin Discussion / Re: Let's Talk about Scamcoins - Researching for Let's Talk Bitcoin! show on: May 24, 2013, 09:59:35 PM
That's one reason I see alt-coins as strengthening cryptocurrency overall; they can sit back and watch what works and what doesn't for Bitcoin and learn from mistakes.

Except they're not learning from Bitcoin's mistakes; how many alt coins have fixed the problems on Bitcoin's hard-fork wish list?
196  Bitcoin / Mining / Re: BFL - butterfly labs - a SAD state of affairs on: May 22, 2013, 06:19:36 PM
As long as no one confirms that we've received their order BFL can say what they want....

I received my pre-ordered (day 2, I think) Jalapeno today.
197  Bitcoin / Development & Technical Discussion / Re: Can't redeem simple non-standard transaction on testnet on: May 21, 2013, 08:37:52 PM
Yes, after NUMEQUALVERIFY the stack will be empty, and for a script to be valid it must leave a true value on the stack.

Use NUMEQUAL and it should work.
198  Bitcoin / Bitcoin Discussion / Re: The Bitcoin Foundation is TOXIC and must dissolve, plus a call to action on: May 21, 2013, 07:54:28 PM
Couple years ago it was "Don't talk to the CIA! They're Evil, and will Destroy Bitcoin!"

Now it is "Don't get involved in DC lobbying! That's Evil, and will Destroy Bitcoin!"

In a few more years, I bet it'll be "Don't go to the United Nations! They're Evil, and will Destroy Bitcoin!"

I'll quote myself from a related thread on google+

Quote

Walking along the beach this afternoon, enjoying the California sunshine, I think I realized where the fundamental disagreement lies.

Financial privacy / freedom is a larger issue than Bitcoin, and I personally think it would be better to fight that fight separately from Bitcoin.  Yes, Bitcoin is a great tool that will (I hope) bring us greater privacy/freedom. But I see advocating for Bitcoin as separate from advocating for financial privacy/freedom in general.

So: I think if you want financial privacy/freedom in general, then there is at least one US organization dedicated to that goal (http://freedomandprosperity.org/ -- we should get them to accept Bitcoin donations). I hate reinventing wheels, and am a big believer in focused organizations and projects as the way to get things done, so I think the Bitcoin Foundation should concentrate on making Bitcoin successful.
199  Bitcoin / Development & Technical Discussion / Re: Dealing with SHA-256 Collisions on: May 13, 2013, 02:45:50 PM
Correct me if i'm wrong!

You are wrong.  If Bitcoin was using (double) MD5 for its proof-of-work hashing algorithm, we'd be just fine.
200  Bitcoin / Development & Technical Discussion / Re: Detecting forks with bitcoind on: May 11, 2013, 07:00:11 PM
If there is a longer fork with more work that your node thinks is invalid, you'll get this alert:

    Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.

(see the GetWarnings() function in main.cpp).

If you are on the fork with the most work... I suppose if the second-best chain was forked more than 6 blocks back and contained more than... oh,  5 blocks and the timestamp on the last block in that chain was less than ?an hour ago? that could trigger another alert.

All that might be tricky to implement-- either (or both) forks might themselves have forks.  Or, theoretically, there could be three or more active forks, some of which might have equal proof-of-work...
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 ... 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!