Bitcoin Forum
May 09, 2016, 01:01:45 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 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 114 »
501  Bitcoin / Development & Technical Discussion / Re: About proposed double-spend alerts in "Two Bitcoins at the Price of One" on: September 07, 2012, 02:08:15 PM
What stops an attacker from pre-generating tens or hundreds of thousands of alert messages (for tens or hundreds of thousands of their own transactions that the previously put into the chain) and then sending them to the network all at once?

Goal would be to keep the network busy checking the alert signatures.
502  Bitcoin / Development & Technical Discussion / Re: New vulnerabilities in the advent of off-the-shelf ASIC mining on: September 07, 2012, 02:20:19 AM
First: I think it is extremely unlikely that somebody would spend a million dollars on an attack that takes months to pull off, doesn't benefit the attacker at all, is easy to fix, and that would be easy for the network to recover from.

The only way to recover from these attacks is by downloading a new version of the client with a new checkpoint with a much higher block difficulty. I can't think of any other possible patch. Maybe the interval between new releases
during the transition from GPUs to ASICs could be decreased.
Good idea, and easy to do.

I've got a half-finished "user-defined checkpoint" patch in my personal git tree, so users, merchants, and big mining pools can decide for themselves to add checkpoints on-the-fly (via an 'addcheckpoint' RPC command) to protect against this type of attack.
503  Bitcoin / Development & Technical Discussion / Re: About proposed double-spend alerts in "Two Bitcoins at the Price of One" on: September 06, 2012, 10:12:27 PM
So miners should change the algorithm to choose the right transaction when a double-spend is detected: choose the one that pays more fees.
Good point. I assume that miners will choose to mine the version of a transaction with the highest fee-per-kilobyte, since that will give them the best profit, but actually changing the code to implement that policy has been controversial when I've brought it up before.

To fight transaction spam, I think the relaying logic will need to get smarter, too.  A large, expensive-to-verify double-spend should be way down on the "stuff that should be relayed when there is enough bandwidth" list.

Quote
(B) How to allow a honest user to replace a transaction because of, for example, low fees specified in the first one?

You have to mark transaction in the pool to be automatically removed after some time, with some type of priority queue structure to allow fast search and removal of old transactions.

Marks in prevouts are lightweight, and easy to wipe out. Just erase them all every 10 minutes.

That's a different issue, and a new feature. I think the best way to implement that feature is "child pays for parent" (see https://github.com/bitcoin/bitcoin/pull/1647 for a proposed implementation), and then the user can broadcast a high-fee pay-to-self child transaction to get the parent accepted into a block.
504  Bitcoin / Development & Technical Discussion / Version 0.7.0 release candidate 3 ready for testing on: September 06, 2012, 07:59:48 PM
Bitcoin version 0.7.0 release candidate 3 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/test/

Unless another critical bug is found, this should be the final 0.7.0 release.

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 were running on Linux with a version that might have been compiled
with a different version of Berkeley DB (for example, if you were using an
Ubuntu PPA version), then run the old version again with the -detachdb
argument and shut it down; if you do not, then the new version will not
be able to read the database files and will exit with an error.

Incompatible Changes
--------------------
* Replaced the 'getmemorypool' RPC command with 'getblocktemplate/submitblock'
  and 'getrawmempool' commands.
* Remove deprecated RPC 'getblocknumber'

Bitcoin Improvement Proposals implemented
-----------------------------------------
BIP 22 - 'getblocktemplate', 'submitblock' RPCs
BIP 34 - block version 2, height in coinbase
BIP 35 - 'mempool' message, extended 'getdata' message behavior


Core bitcoin handling and blockchain database
---------------------------------------------
* Reduced CPU usage, by eliminating some redundant hash calculations
* Cache signature verifications, to eliminate redundant signature checks
* Transactions with zero-value outputs are considered non-standard
* Mining: when creating new blocks, sort 'paid' area by fee-per-kb
* Database: better validation of on-disk stored data
* Database: minor optimizations and reliability improvements
* -loadblock=FILE will import an external block file
* Additional DoS (denial-of-service) prevention measures
* New blockchain checkpoint at block 193,000


JSON-RPC API
------------
* Internal HTTP server is now thread-per-connection, rather than
  a single-threaded queue that would stall on network I/O.
* Internal HTTP server supports HTTP/1.1, pipelined requests and
  connection keep-alive.
* Support JSON-RPC 2.0 batches, to encapsulate multiple JSON-RPC requests
  within a single HTTP request.
* IPv6 support
* Added raw transaction API.  See https://gist.github.com/2839617
* Added 'getrawmempool', to list contents of TX memory pool
* Added 'getpeerinfo', to list data about each connected network peer
* Added 'listaddressgroupings' for better coin control
* Rework gettransaction, getblock calls. 'gettransaction' responds for
  non-wallet TXs now.
* Remove deprecated RPC 'getblocknumber'
* Remove superceded RPC 'getmemorypool' (see BIP 22, above)
* listtransactions output now displays "smart" times for transactions,
  and 'blocktime' and 'timereceived' fields were added


P2P networking
--------------
* IPv6 support
* Tor hidden service support (see doc/Tor.txt)
* Attempts to fix "stuck blockchain download" problems
* Replace BDB database "addr.dat" with internally-managed "peers.dat"
  file containing peer address data.
* Lower default send buffer from 10MB to 1MB
* proxy: SOCKS5 by default
* Support connecting by hostnames passed to proxy
* Add -seednode connections, and use this instead of DNS seeds when proxied
* Added -externalip and -discover
* Add -onlynet to connect only to a given network (IPv4, IPv6, or Tor)
* Separate listening sockets, -bind=<addr>


Qt GUI
------
* Add UI RPC console / debug window
* Re-Enable URI handling on Windows, add safety checks and tray-notifications
* Harmonize the use of ellipsis ("...") to be used in menus, but not on buttons
* Add 2 labels to the overviewpage that display Wallet and Transaction status (obsolete or current)
* Extend the optionsdialog (e.g. language selection) and re-work it to a tabbed UI
* Merge sign/verify message into a single window with tabbed UI
* Ensure a changed bitcoin unit immediately updates all GUI elements that use units
* Update QR Code dialog
* Improve error reporting at startup
* Fine-grained UI updates for a much smoother UI during block downloads
* Remove autocorrection of 0/i in addresses in UI
* Reorganize tray icon menu into more logical order
* Persistently poll for balance change when number of blocks changed
* Much better translations
* Override progress bar design on platforms with segmented progress bars to assist with readability
* Added 'immature balance' display on the overview page
* (Windows only): enable ASLR and DEP for bitcoin-qt.exe
* (Windows only): add meta-data to bitcoin-qt.exe (e.g. description)

Internal codebase
-----------------
* Additional unit tests
* Compile warning fixes


Miscellaneous
-------------
* Reopen debug.log upon SIGHUP
* Bash programmable completion for bitcoind(1)
* On supported OS's, each thread is given a useful name
505  Bitcoin / Development & Technical Discussion / Re: About proposed double-spend alerts in "Two Bitcoins at the Price of One" on: September 06, 2012, 04:32:31 PM
Right, you do have to remember them for at least a little while...  Replace "relay but don't remember" with "relay and forget as soon as possible."
506  Bitcoin / Development & Technical Discussion / Re: About proposed double-spend alerts in "Two Bitcoins at the Price of One" on: September 06, 2012, 04:01:09 PM
Sergio:

Is a new type of message necessary?

How about just making the transaction relay rules:

1) If the transaction has inputs that conflict with one already in the best blockchain, drop it.
2) If the transaction has inputs that conflict with another transaction in the memory pool, and it is the first such conflicting transaction, check the new transaction's signatures and if they're OK mark the memory pool transaction as "saw a double spend". Then relay the conflicting transaction (but don't otherwise remember it).

Rule (1) is to prevent an attacker from taking a bunch of her old, already-in-the-blockchain outputs and trying to generate a "double spend alert storm" by sending bogus double-spend attempts for them.

Rule (2) is to limit the amount of network traffic / signature checks an attacker can create to be twice what they can generate today (attackers can, and do, try to flood the network with transactions, but transaction fees and the free transaction relay policy keeps them in check).

The GUI/RPC should definitely show attempted-double-spend memory pool (0-conf) transactions as "BEWARE".

I think those rules will flood the network with the double-spend attempt, alerting merchants/users that something odd is happening. Without making it possible for an attacker to get the network flooded with gazillions of double-spend alert messages.

507  Economy / Speculation / Re: Bitcoin Project will be making a major announcement in September on: September 06, 2012, 02:42:05 AM
Idk, maybe my opinion will change after the announcement and it will be obvious why it had to be kept secret.

"Hey, I've got this fantastic idea!"

"Really!  Tell me all about it!"

"We're going to blah blah blah."

"Uhh... did you talk to a lawyer about that? That might be illegal."

"Uhh... really? no."

"And where will you get the money to do it?"

"Uhhh... haven't figured that out yet."

"And if I want to participate, what should I do?"

"Uhh... I dunno, we don't really have a process for that yet..."

I made the mistake of asking a reporter when her deadline was, because if it was far enough away I could tell her about the neat idea. I should have kept my mouth shut or sworn her to secrecy.

Announcing a half-baked idea is counterproductive; you'll just get a gazillion questions that you can't answer, or, even worse, people will assume they know the answers and then be disappointed when it turns out the idea they thought they heard you describe isn't the same idea they thought they heard.

Announcing a fully-baked idea and then modifying it based on what everybody thinks and how it works out in practice is the right way to do things, in my humble opinion.
508  Bitcoin / Bitcoin Discussion / Re: why aren't we, the community, regularly paying the lead developers of bitcoin? on: September 06, 2012, 02:28:06 AM
remember that gavin has said elsewhere on this forum, that they just see the satoshi client as a proof-of-concept, nothing more.

I've said that I think the download-and-install-software-on-your-PC is a mostly-dead way of using software, and that the vast majority of people using Bitcoin in a year or three will be using it via a web application or on their smart phone. That's half of the reason why I don't think improving the UI is a high priority right now (the other half is because I think solving wallet security and backup issues is critical).

RE: 2112 and GAAP:  "patches welcome."  I don't know nuthin about GAAP, so if you're complaining that the reference implementation doesn't adhere to them then I'm not surprised. Feel free to fix that, or write a detailed proposal on what's wrong, why it'll cause problems, and how it ought to be fixed.

RE: funding development: funding open source software projects is tricky; if done poorly you end up with a couple of paid developers and lots of disappointed unpaid former contributors who decide "I'm not gonna work if I'm not gonna get paid."

That said... stay tuned, and I'll say more when I can.
509  Economy / Speculation / Re: Bitcoin Project will be making a major announcement in September on: September 05, 2012, 06:03:06 PM
this situation makes bitcoin seem like it's run by a group of people with inside info.  decentralized my ass.

this makes me feel left out.
You're missing the point of Bitcoin if you feel left out. You can be as involved as you want to be, just go make something happen-- find something you think needs doing, recruit some people to help if you need help, and do it. Are you waiting for an invitation or permission from somebody?
510  Economy / Service Announcements / Re: Blockchain.info - Bitcoin Block explorer & Currency Statistics on: September 05, 2012, 05:13:59 PM
Yes, please don't create lots of unspendable scriptPubKeys. There are more prunable ways of embedding messages into transactions. And there are even better ways of associating messages with transactions, so only people involved with the transaction can read the message (if that's desired).

In other words, lets figure out how to do this the right way. The way you're doing it now will stop working as soon as the network upgrades anyway (0-value outputs are nonstandard as of the 0.7 release).
511  Bitcoin / Bitcoin Discussion / Re: Bitcoin is quantum-computing proof? on: September 04, 2012, 07:58:27 PM
From "Operator Imprecision and Scaling of Shor's Algorithm" (2008):

Quote
In this paper, we show that the polynomial scaling of SA (Shor's algorithm) is destroyed by input errors to the QFT part of the algorithm. We also show that Quantum Error Correcting Codes (QECC) are not capable of suppressing errors due to operator imprecision and that propagation of operator precision errors is sufficient to severely degrade the effectiveness of SA. Additionally we show that operator imprecision in the error correction circuit for the Calderbank-Shor-Steane QECC is mathematically equivalent to decoherence on every physical qubit in a register. We conclude that, because of the effect of operator precision errors, it is likely that physically realizable quantum computers will be capable of factoring integers no more efficiently than classical computers.
I don't see any published rebuttals in a quick Google Scholar search. Maybe there will be a breakthrough (or already has been... any QC wizards listening here?) in handling the fuzziness of quantum calculations as you scale up the number of qbits, but 256-bit ECDSA looks pretty darn secure to me right now.
512  Other / Meta / Re: [POLL] should the "securities," "lending," etc. sub-fora be moved to a new site? on: September 04, 2012, 07:02:39 PM
I'd like bitcointalk.org to be in the spirit of the Internet's original ".org" -- For Non-Commercial Use Only.

But... it is hard to figure out what is Commercial Use and what isn't (e.g. some mining pools are non-profit, some for-profit, and I'm sure there are some in the fuzzy middle), which is why there really aren't any rules for .org any more.

513  Bitcoin / Development & Technical Discussion / Re: [Bug?] signrawtransaction of multisig with explicit privkey doesn't work on: September 04, 2012, 01:36:14 PM
So either a fifth optional argument for the P2SH scripts or extending the 3rd argument to include both privkeys and P2SH script would do the job.
I'm leaning towards extending the 2nd argument, to give previous inputs and, if the previous inputs are P2SH, previous inputs scripts.

Along with a new 'rawmultisigaddress' that is just like addmultisigaddress, but doesn't add the redemption script to the wallet but instead returns it.

Quote
... or was it the addmultisigaddress that added the P2SH scripts?
addmultisigaddress added the P2SH scripts to the wallet.

RE: when can you expect a fix:

It is too late to add new RPC features to the 0.7 release, so no fix until the next release.
514  Bitcoin / Development & Technical Discussion / Re: [Bug?] signrawtransaction of multisig with explicit privkey doesn't work on: September 03, 2012, 01:56:09 PM
Bug. I never tested the combination of signing a pay-to-script-hash transaction with non-wallet private keys.

I'm not 100% sure how to fix it, though. The problem is private keys, public keys, and P2SH scripts are all stored in a "keystore." When you give the third argument to signrawtransaction, it creates a keystore that contains just the private keys (and the corresponding public keys) that you give, and uses that to sign the transaction.

There's currently no way to give it the P2SH script that corresponds to 34y6HmY6zTH51KTC9vd36HasNL4kLKcisC, but the transaction signing code needs that information.

I think the right fix is to give signrawtransaction both the private key(s) and any P2SH information needed...
515  Economy / Long-term offers / High-interest, low-risk 'investments' are like perpetual motion machines on: September 02, 2012, 11:38:53 PM
I was sent a personal message by somebody saying that the burden of proof that something is a scam should be on the person accusing the scammer.  If they can't PROVE it, then they should shut up.

I disagree. I think the burden of proof is on people "guaranteeing" high returns.

Here's how I think of it:

Imagine you see somebody claiming they have invented a perpetual motion machine.

You claim bullshit, because that's against the laws of physics and all previous experience.

Now they send you an email, saying "... before making such accusations you need to PROVE that it cannot work."

Foolproof schemes to make high interest at low risk are the financial world's perpetual motion machines. They do not exist.

Perpetual motion machines may not be scams; there are misguided people who really do believe that they've violated the laws of physics and will prove all of those pesky scientists wrong. I'm sure there are people who truly believe that they've invented foolproof methods of investing lots of money with no risk, too, but I'm equally sure they're delusional.
516  Economy / Long-term offers / Re: ★ VESCUDERO's Risk-free Weekly Term deposits at 1.5% ★ on: September 02, 2012, 10:14:15 PM
Micon could you please  get your ass out of all these threads I like to follow? You're making it quite hard for me with all he off-topic unsubstantiated nonsense you're constantly repeating. If you do not comply I will start reporting every such post of yours to the modsto try ad get you removed from these forums instead and adviseothers to do the same.
Yeah, don't do that, you'll annoy some of us moderators.

I think Micon is doing the moral thing, warning people of what he thinks are scams.

I think they're scams, too. It is impossible to get risk-free 1.5% weekly interest, I don't care how good you are at "playing the market" or "choosing who to lend to."
517  Bitcoin / Development & Technical Discussion / Re: cbitcoin - Bitcoin implementation in C. Currently in development. on: September 02, 2012, 04:13:01 PM
Does valgrind really not work on Mountain Lion?  Good reason for me not to upgrade... (runs great on Snow Leopard).
518  Other / Meta / Re: "Long-term offers" - gonna have to tackle this 1 eventually on: September 02, 2012, 03:56:26 PM
Securities scares me because in the USA there are strict laws with even TALKING about securities.

I know, I know, Congress is supposed to make no law abridging freedom of speech. I worry that won't stop the SEC from seizing the bitcointalk.org domain name for promoting unlicensed securities.

I think a separate top-level domain for everything under the Marketplace heading would be the right thing to do.
519  Other / Meta / Re: "Long-term offers" - gonna have to tackle this 1 eventually on: September 02, 2012, 03:27:03 PM
I agree with Micon. I'm embarrassed by 'Long Term Offers' and scared by 'Securities'.
520  Economy / Gambling / Re: Hunger Coins: An offer you can't refuse on: September 01, 2012, 03:49:52 PM
I'm sorry to hear that. All those people in the lending subforum who borrow and lend for profit must all be ponzi schemes too if we follow that logic. And we can also include everyone with credit cards too. Hmmmm, how then do we address it?
You address it by explaining where the bitcoins come from for the 'guaranteed' payouts.

Credit cards make money by charging merchants a fee, charging interest on late payments, etc. And they mitigate their risk by running credit reports on borrowers.

Legitimate lenders do something similar.

So, I'll ask again: what is your business model?  How will you make the money to payback the people who are sending you X bitcoins and expecting to get X+Y back in a day?
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 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 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!