Bitcoin Forum
May 09, 2016, 01:03:27 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 77 78 79 80 81 82 83 84 85 86 87 88 89 90 ... 114 »
781  Bitcoin / Development & Technical Discussion / Re: send BTC generate new address? on: February 15, 2012, 09:16:15 PM
If I have 50 BTC on my address and I want to send 10 BTS to another address then the rest of 50 BTC = 40 BTC will sent to a new generated address.
I know that was integrated to make the flow more anonymous.

Is there a possibilty to deactivate this function?

Because I need a clean simple transaction history where I and other users can check it.

I've got a "noprivacy" branch of bitcoin that I use for the Faucet:
  https://github.com/gavinandresen/bitcoin-git/tree/noprivacy

Instead of creating a new address for change, it uses one of the input's addresses.

It works nicely if your entire bitcoin balance is one "account", but will fail if you're using the accounts feature to keep track of separate balances (which is why it will probably never be a mainline feature).

782  Bitcoin / Development & Technical Discussion / Re: Meeting Tuesday 21:00 UTC #bitcoin-dev Freenode IRC on: February 15, 2012, 09:06:22 PM
Meeting summary posted to the bitcoin-development mailing list (link)

IRC logs here.
783  Bitcoin / Development & Technical Discussion / Re: Researchers crack online encryption system - Bitcoin affected? on: February 15, 2012, 08:42:19 PM
This doesn't affect Bitcoin at all, because the ECDSA algorithm that Bitcoin uses does not use pairs of prime numbers to do it's thing.
784  Bitcoin / Development & Technical Discussion / Re: Meeting Tuesday 21:00 UTC #bitcoin-dev Freenode IRC on: February 14, 2012, 02:49:14 AM
Tomorrow at 21:00 UTC on #bitcoin-dev I'd like to talk about:

Status of BIP 16 support (progress towards 50% hashing power).

Protocol change: checksum in version messages coming up Feb. 20.

Duplicate coinbase issue (and requiring block height in the coinbase as a solution).
785  Economy / Service Discussion / Re: TradeHill - shutting down trading / deposits and returning all client funds on: February 14, 2012, 12:46:17 AM
AUD   1.0505165637
CLP   3.5642268
EUR   0.4505647183
LR   0.5729219078
USD   2.0118972398

...and no way of getting rid of these soon (except the USD, but then I'd have to trust bitinstant + mtgox or other bitinstant partners - which I don't).
 Embarrassed

I've got about $12 USD in my TradeHill account:  Jered, please keep it, you deserve it, I know how hard you've worked and how hard a fight it is to interface with our designed-in-the-1960's-duct-tape-and-bailing-wire rats-nest-of-regulations banking/finance system.
786  Bitcoin / Bitcoin Discussion / Re: Idea: A fund for an alternative Bitcoin development team. on: February 11, 2012, 12:57:42 AM
I will be justifying my criticism very shortly.

If you've got a great business model and funding for a much better bitcoin client, more power to you!

If you're planning on defacing one of the web servers that I haven't been keeping up-to-date (because I'm busy doing Bitcoin-related things) or hacking my gmail account to prove that I'm not The World's Best Security Expert... then I'll save you the trouble:

I am not the World's Best Security Expert.
I am not the World's Best Programmer.
I am not a cryptographer.
I am not an expert on finance or banking or monetary systems.
I am not an expert on leading open source projects.

And I hope someday I get replaced as the technical lead for this project. I'm sure there are lots of people better qualified than me, I'm just doing the best I can to try to help make Bitcoin a success.

787  Bitcoin / Pools / Re: [300 GH] Eligius pool: ~0Fee SMPPS, no reg, RollNtime, hop OK, BTC+NMC merged! on: February 10, 2012, 02:52:19 PM
I hope they find and prosecute the bastards; DDoSing somebody because you disagree with them is never OK.

In fact, I think there is never a situation where DDoSing is OK, even if you're trying to accomplish something good (philosophical discussions about ends justifying the means should move to off-topic...)
788  Bitcoin / Bitcoin Discussion / Re: Bitcoin in danger!? Received <Sent!?! on: February 10, 2012, 02:27:33 AM
Don't panic.

roconnor has been experimenting with spending "duplicate coinbase transactions" on the testnet.  Block explorer is confused, and isn't seeing the 50 bitcoins generated to that address in testnet block 45,442 (because the generation transaction has the same ID as the generation transaction in block 45,333).

Expect code changes before the 0.6 release is final to discourage and eventually prohibit accepting blocks with duplicate coinbase transactions; although we can't see a way to exploit this weirdness to cheat anybody (it is easy to cheat yourself out of bitcoins using duplicate coinbase transactions that cannot be spent), it's definitely not a good thing.
789  Bitcoin / Development & Technical Discussion / Re: Version 0.6 release candidate 1 on: February 09, 2012, 07:04:43 PM
Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens?

You are the Quality Assurance department.  A test plan is an excellent idea, could you write one up and post it on the wiki and ask for volunteers to help test?

Gavin, will Btcoin-QT support plain M-Of-N transactions and P2SH transactions or will it be etiher-or?

I don't know, the GUI for multisignature transactions hasn't been designed yet. But I imagine it will be simpler to always produce P2SH transactions, just as the client always produces OP_HASH160 transactions and has no option to produce plain OP_CHECKSIG transactions.

I assume that both forms will be supported for multisig payments into your wallet (but detailed discussion on how to support multisig in the GUI should happen somewhere other than this thread).
790  Bitcoin / Development & Technical Discussion / Re: Version 0.6 release candidate 1 on: February 09, 2012, 02:46:10 PM
Do these builds use a gitian-like build process?
Yes, thanks for reminding me:  I just uploaded gitian signatures for the win32 and linux 0.6rc1 builds to:
  https://github.com/bitcoin/gitian.sigs

The win32 build was not deterministic, though.  There's a pull request to fix that.

The OSX binary is not gitian-built.

791  Bitcoin / Development & Technical Discussion / Version 0.6 release candidate 1 on: February 09, 2012, 01:35:41 AM
Re-posted from the bitcoin-development mailing list:


I'd like version 0.6 to get lots of review, "soak time" and testing, so
please download and run release candidate 1 from:
 http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/

You can review the code changes using github's compare feature:
 https://github.com/bitcoin/bitcoin/compare/v0.5.2...v0.6.0rc1

Please report bugs using the github issue tracker.


Release notes:

NEW FEATURES SINCE BITCOIN VERSION 0.5
--------------------------------------
Bitcoin-Qt can display and save QR codes for sending
and receiving addresses.

New context menu on addresses to copy/edit/delete them.

New Sign Message dialog that allows you to prove that you
own a bitcoin address by creating a digital
signature.

Wallets created with this version of bitcoin will
use 33-byte 'compressed' public keys instead of
65-byte public keys, resulting in smaller
transactions and less traffic on the bitcoin
network. The shorter keys are completely
compatible with older versions.

New command-line argument -blocknotify=<command>
that will spawn a shell process to run <command>
when a new block is accepted.

validateaddress JSON-RPC api command output includes
two new fields for addresses in the wallet:
 pubkey : hexadecimal public key
 iscompressed : true if pubkey is a short 33-byte key

New JSON-RPC api commands for dumping/importing
private keys from the wallet (dumprivkey, importprivkey).

New JSON-RPC api command for getting information about
blocks (getblock, getblockhash).

New JSON-RPC api command for getting extra information
related to mining (getmininginfo).


NOTABLE CHANGES
---------------

The -nolisten, -noupnp and -nodnsseed command-line
options were renamed to -listen, -upnp and -dnsseed,
with a default value of 1. The old names are still
supported for compatibility (so specifying -nolisten
is automatically interpreted as -listen=0; every
boolean argument can now be specified as either
-foo or -nofoo).

The -noirc command-line options was renamed to
-irc, with a default value of 0. Run -irc=1 to
get the old behavior.


PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS
---------------------------------------------------

This release has preliminary support for multisignature
transactions-- transactions that require authorization
from more than one person or device before they
will be accepted by the bitcoin network.

Prior to this release, multisignature transactions
were considered 'non-standard' and were ignored;
with this release multisignature transactions are
considered standard and will start to be relayed
and accepted into blocks.

It is expected that future releases of Bitcoin-Qt
will support the creation of multisignature transactions,
once enough of the network has upgraded so relaying
and validating them is robust.

For this release, creation and testing of multisignature
transactions is limited to the bitcoin test network using
the "addmultisigaddress" JSON-RPC api call.

Short multisignature address support is included in this
release, as specified in BIP 16. Run with -bip16=0 to
turn off support for BIP 16.
792  Bitcoin / Pools / Re: [419 GH] Eligius pool: ~0Fee SMPPS, no reg, RollNtime, hop OK, BTC+NMC merged! on: February 05, 2012, 04:30:41 PM
Since it seems a lot of pools have been hacked (and balances emptied) recently, I just thought I'd let everyone know that Eligius should be immune to this attack. Since we generally payout in generation, I can safely encrypt the pool wallet, and never unlock it on the actual pool server (ie, only create manual payout transactions on an offline system).

But what if somebody hacked into your server and modified the code that decides which addresses get paid out?

If they were smart, they'd shave just a little bit from everybody's payout and insert a payout to themselves... I imagine it could take quite a while before anybody noticed.
793  Bitcoin / Development & Technical Discussion / Re: BIP 22? on: February 03, 2012, 03:33:03 PM
Gavin's call still, of course.  I will be just as tickled to see BIP 16 move into place, ultimately I just want to see multisig happen but don't care how it gets done, and BIP 16 is more than good enough for me.

I used my Phone-a-Friend and Ask the Audience, and I'm locking in BIP 16 as my Final Answer (follow the link if you don't get the stale pop culture reference).
794  Bitcoin / Bitcoin Discussion / Re: How Open Source Projects Survive Poisonous People on: February 03, 2012, 12:37:24 PM
Can't we hire respectable white hats to do a professional audit (with pledges)?

Good idea. Who wants to volunteer to do the fundraising and organize this, and let me know how I can help?

795  Bitcoin / Alternative clients / Re: Protocol-level transaction fuzzing tool on: February 02, 2012, 02:17:48 PM
Have you found any cool vulnerabilities with this?
No, bitcoind is solid as a rock, both with and without the BIP 16 patches applied.

796  Bitcoin / Bitcoin Discussion / Re: A startling thought crossed my mind on: February 01, 2012, 09:48:21 PM
RE: lightweight versus heavyweight clients:

First: lightweight clients (like Multibit) that don't store the entire blockchain must rely on the rest of the network to confirm that transactions are valid.  They can't check for themselves (this is true today, and BIP 16 doesn't change that at all).

Full clients do check, but it is still not safe for them to accept 0- or 1-confirmation transactions; an attacker might be sending them an attempted double-spend (and the network might be still be trying to figure out which 'side' of the double-spend will win).  That is also true today.

"Backwards compatibility" means that all valid transactions created by the new software will be accepted as valid transactions by the old software.

But, after BIP 16 is supported by a majority of the network, there could exist transactions that the old software considers valid but the new software rejects as invalid.

So... does BIP 16 make things riskier for people running old software?  Yes, a tiny bit, in the very particular case of 1-confirmation transactions. And that particular attack requires that the attacker manage to mine a block that they know will be found invalid (which is expensive). Again, if you get bitcoins from somebody you do not trust then you should wait until they have 3 or more (6 if you want to be extremely safe) confirmations before considering the payment final.

If you want all the technical details of why BIP 16 does NOT increase the risk for 0-confirmation transactions but does for 1-confirmation transactions... ask me another day (it has to do with how the old software recognizes "Standard" transactions and won't even show you transactions it doesn't recognize).
797  Bitcoin / Bitcoin Discussion / Re: A startling thought crossed my mind on: February 01, 2012, 07:45:38 PM
Depending on what rule changes you are talking about it doesn't matter if 95% of miners choose to switch to say 50BTC reward forever. The power is with the merchants to reject the false coins.

Please explain to me how they can do that?

They just keep running the code they've been running.   It will reject the 'bad' blockchain being produced by 95% of the miners, and accept the 'good' chain being produced by the other 5%.
798  Bitcoin / Development & Technical Discussion / Re: BIP 22? on: February 01, 2012, 06:40:45 PM
No, bad idea, two chains cannot peacefully coexist for more than a few dozen blocks, they would eventually make a complete mess out of users' wallets.

799  Bitcoin / Bitcoin Discussion / Re: BIP 16 / 17 in layman's terms on: February 01, 2012, 06:03:54 PM
You should be able to use your present wallet but would probably be required to upgrade your client.

No, you don't have to upgrade your client to receive coins from somebody using a BIP 16 multisignature wallet.
800  Bitcoin / Development & Technical Discussion / Re: BIP 22? on: February 01, 2012, 02:37:51 PM
I apologize for the shouting, it's been a hard couple of weeks.  And thanks for the support.

Very quickly, the problem with any chain split is double spends.  An attacker can spend his bitcoins twice, once using CHECKSIGEX and some script instead of a public key.  They can wait for the coins to confirm on the "new" chain, and then they can spend the coins again, using CHECKSIG, on the old chain.

The result would be massive confusion and chaos as those "old" users slowly upgraded and then found their wallets had NEGATIVE balances after the upgrade.
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 77 78 79 80 81 82 83 84 85 86 87 88 89 90 ... 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!