Bitcoin Forum
May 09, 2016, 12:59:20 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 ... 114 »
101  Bitcoin / Development & Technical Discussion / Re: Ideas for distributed bitcoin development on: May 30, 2014, 12:42:25 AM
I thought the BCF is supposed to help pay for dev efforts

The Bitcoin Foundation does help pay for dev efforts; it pays me, Wladimir, and Cory Fields (and gives quarterly grants to fund other worthwhile efforts).

I disagree with the original poster; Bitcoin development is increasingly decentralized over time. It started out as centralized as it could possibly be-- Satoshi wrote all the code himself (or herself or their-selves).

Now we have multiple implementations, multiple altcoins, and multiple wanna-be-Bitcoin-2.0 contenders, all with their own dev person-or-team (well, some altcoins probably don't have any developers).

As for your specific ideas: go for it. If you think they're good ideas, implement them (or hire or convince somebody to implement them) and see what happens.
102  Bitcoin / Development & Technical Discussion / Re: BIP70 : Test vectors ? on: May 25, 2014, 02:55:06 PM
This suck Sad
I would prefer having less, or no explanation page for a BIP but some rudimentary test vectors, than a novel without one. Sad

Feel free to create some; code here: https://github.com/gavinandresen/paymentrequest
103  Bitcoin / Development & Technical Discussion / Re: Problems with multisig transactions in bitcoind with default account in regtest. on: April 13, 2014, 04:43:23 PM
transactions send via sendrawtransaction are always debited from the default "" account. Raw transactions and accounts are not designed to work together, use one or the other .

And preferably not accounts: unless somebody steps up and volunteers to make the accounts feature "industrial-strength" (scalable, integrates with whatever back-end database your company is using to track user information, can be robustly backed up, etc) it is very likely it will be deprecated and then dropped.
104  Bitcoin / Development & Technical Discussion / Re: Technical info about transaction fees on: April 13, 2014, 04:36:31 PM
not if priority is greater than 57600000, according to the official wiki.

There is a lot of competition for the free transaction area in blocks these days; you need a much higher priority to get confirmed quickly, 57.6 million is not enough any more.

A future version of the reference implementation wallet will automatically estimate the priority needed.
105  Bitcoin / Development & Technical Discussion / Re: Can Bitcoin Core be compromised by Heartbleed - are private keys exposed? - How? on: April 11, 2014, 04:12:59 PM
On further testing, it looks like OSX and Linux payment protocol requests with the released 0.9.0 binaries are not vulnerable.

The released Windows 0.9.0 binaries are vulnerable, so Wladimir just sent an alert message urging everybody running 0.9.0 to upgrade.

But apparently only few developers actually do that and bitcoin core devels don't seem to be on that list... at last as far as I had checked this code.
So, shame on you too! Smiley
Check again; see the use of CKeyingMaterial/CPrivKey which uses a secure_allocator (which asks the operating system not to swap the memory to disk, and which zeros memory on free). If I recall correctly, the RPC importprivkey should be the only place where the normal memory allocator is used (the keys exist as ordinary hex strings in memory before they are processed by the importprivkey code).

Careful review (and testing and patches) is always welcome, of course. You shouldn't trust my famously faulty memory.
106  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core compromised by Heartbleed - private keys exposed - How? on: April 10, 2014, 09:37:21 PM
https://github.com/Lekensteyn/pacemaker is a little SSL server to test SSL clients for heartbleed vulnerability.

I installed Bitcoin Core version 0.9.0 on my Mac (compiled against the vulnerable openssl 1.0.1f), created a web page to launch a payment request fetch from pacemaker...

... and I get good news:
Code:
Connection from: 127.0.0.1:62937
Possibly not vulnerable

Step-by-step so you can help test on other OS'es :


pacemaker.py should report a connection, and then either say "Client returned blah bytes" or "Possibly not vulnerable"

It looks to me like pacemaker.py IS working; visiting https://127.0.0.1:4433/ in Chrome pacemaker tells me:
Code:
Connection from: 127.0.0.1:62514
Client returned 7 (0x7) bytes
0000: 15 03 03 00 02 02 2f                             ....../

This isn't a definitive "no need to worry even if you HAVE clicked on payment-protocol-enabled bitcoin: links at an untrustworthy website" ... but given the evidence I've seen, it seems to me extremely unlikely anybody's private keys have been compromised.
107  Bitcoin / Development & Technical Discussion / Re: Why a fixed transaction fee? on: April 03, 2014, 03:30:34 PM
Not quite right. Miners can and will mine things with a lower fee. Many nodes will simply not forward the transactions however.

For low-priority transactions, it doesn't look to me like many miners are accepting lower fees.

Right now, a 999-byte transaction paying the reference-implementation-default fee of 0.0001 BTC will wait 2-3 hours to get into a block.

A typical 250-byte transaction paying the default 0.0001 BTC fee will see its first confirmation in 5 or 6 blocks (about an hour on average). If you want your transaction to confirm quickly, then right now you need to pay about double the default fee.

Some results running https://github.com/bitcoin/bitcoin/pull/3959 (more review/testing welcome) :

Code:
$ for i in {1..25}; do ./bitcoin-cli estimatefee $i; done
0.00077821
0.00044643
0.00044444
0.00044248
0.00044248
0.00038911
0.00038760
0.00026810
0.00024752
0.00022831
0.00020040
0.00017513
0.00016155
0.00014706
0.00013802
0.00012531
0.00011779
0.00011013
0.00010363
0.00010111
0.00008905
0.00008636
0.00007474
0.00006743
0.00004444
108  Bitcoin / Development & Technical Discussion / Re: gitian build (Windows client): vm asks for root password when compiling protobuf on: March 24, 2014, 01:04:22 PM
Sounds familiar...

... I think I ran into a similar problem that turned out to be ssh being upset that the file permissions on the id_dsa file used to login to the virtual machine were too permissive (because I was running from a FAT32-formatted USB stick that didn't support file permissions at all, if I recall correctly, which I probably don't).

109  Bitcoin / Bitcoin Discussion / Re: Bitcoin 0.9.0 FINAL is available [Changelog] [Download] on: March 19, 2014, 08:55:15 PM
On the Mac build at least, the "pre-release build" banner is showing. Seems like that flag was not turned off?

This was a release process bug; I re-built/signed/uploaded the OSX .dmg to fix it (and updated the SHASUMS files).

The warning is harmless, and no code was changed, so if you don't want to re-download and install you don't have to.

Thanks to lots of hard work from Luke Dashjr and Cory Fields we should (fingers crossed!) have deterministic OSX builds working before the next release, which will make this kind of error impossible.
110  Alternate cryptocurrencies / Altcoin Discussion / Re: Turing complete language vs non-Turing complete (Ethereum vs Bitcoin) on: February 03, 2014, 01:11:18 PM
Thanks, k99 and Vitalik, that helps clear it up.  I've put "On Transaction Fees, And The Fallacy of Market-Based Solutions" on my to-think-about-deeply list.

I'm curious about this, though:

Precisely; although with the proviso that the first 16 computational steps in contract execution are free, so if a contract is decently written you can't involuntarily send transactions to it to bankrupt it.

If my contract needs more than 16 computational steps to execute, then other people CAN send transactions to it to intentionally bankrupt it? That is what I was worrying about when I said "publish the attacker's transaction and take the fee but ignore any other effects of the transaction, but you'd have to be careful to design THAT mechanism so it couldn't be abused."
111  Alternate cryptocurrencies / Altcoin Discussion / Re: Turing complete language vs non-Turing complete (Ethereum vs Bitcoin) on: February 02, 2014, 05:10:20 PM
Okey dokey... so how do fees work in Ethereum?

Or do you have some other clever distributed way of preventing flood-the-system-with-bogus-contracts DoS attacks?
112  Alternate cryptocurrencies / Altcoin Discussion / Re: Turing complete language vs non-Turing complete (Ethereum vs Bitcoin) on: February 01, 2014, 10:11:26 PM
How do transaction fees work in Ethereum?

One of the non-obvious reasons Bitcoin works is transaction fees are based on the size (in bytes) of the transaction. And since there are no loops executing a transaction, CPU usage is bound by transaction size.

If CPU usage to verify a transaction is NOT related to the transaction size, then you open yourself up to denial-of-service attacks. Like:

Create an Ethereum transaction with a (huge!) fee that will pay for 60 seconds of CPU execution time.
... but craft it so execution takes 61 seconds (or, heck, make it an infinite loop, maybe you'll tickle a bug in the execution termination code).

Now broadcast it.  It will be rejected for insufficient fee, but only after peers have wasted 60 seconds of CPU time. And if the transaction is rejected, the attacker won't pay the fee.

Then tweak it slightly and broadcast it again, maybe from a different IP address if you got banned for bad behavior.


I haven't thought deeply about whether or not there is a way to punish the attacker; my first thought would be to publish the attacker's transaction and take the fee but ignore any other effects of the transaction, but you'd have to be careful to design THAT mechanism so it couldn't be abused.

113  Bitcoin / Bitcoin Discussion / Re: Gavin will visit the Council on Foreign Relations on: January 14, 2014, 02:20:28 AM
I'm usually pretty careful not to call people names.  Did I screw up?

I DO think there are lots of crazy conspiracy theories. I might even believe some of them myself, but that doesn't make me crazy (just "almost certainly wrong.").

RE: child exploitation:  Good example.  We all agree that child exploitation is BAD, right?

We might disagree about what (if anything) we should DO about it, but isn't it worth discussing whether or not there is something we MIGHT do about it?  For example, maybe offering mostly-anonymous bounties to reward anybody who gives information that leads to the arrest and conviction of people abusing children for profit or pleasure is a good idea.  Maybe those bounties could be paid in Bitcoin.

Maybe that is a terrible idea that will have awful consequences, but instead of rational discussion there's a knee-jerk GOVERNMENT BAD! that, in my humble opinion, is counter-productive to making the world a better place.

I don't like people assuming that they know what I'm thinking, or assume that because I'm willing to talk to people that I agree with those people, or assume that because I'm pragmatic about regulation I "want regulation."  For the record:  I'm mostly libertarian, I think we'd be just fine if we replaced 99.911% of regulations with voluntary, private, market-based solutions. But that ain't gonna happen any time soon.


114  Bitcoin / Bitcoin Discussion / Re: Gavin will visit the Council on Foreign Relations on: January 13, 2014, 11:54:00 PM
No, I think that is when he goes to the Bilderberger meet-up (not on google meet-ups btw) ...

Bilderberger meetup is in Barbados this year.  But don't tell anybody, it is a secret.


PS to dewdeded: Mike Hearn and I both own non-US passports, so putting us on Team USA is funny. We should be Team Global Conspiracy (mmm... gotta get T-shirts made...).

115  Bitcoin / Mining speculation / Re: What happens if a Block can't be found? on: January 13, 2014, 09:16:54 PM
No, not possible, given what we know about the properties of SHA256 hashing.
116  Bitcoin / Bitcoin Discussion / Gavin will visit the Council on Foreign Relations on: January 12, 2014, 10:12:24 PM
I've accepted an invitation to do a question and answer session at the Council on Foreign Relations (CFR) in Washington, DC on Thursday, February 6, 2014.

I've been told anything related to the Council on Foreign Relations tickle's peoples Grand Conspiracy buttons, so I thought it would be best to be open about exactly what will happen. I hope it doesn't spark as long a thread as my visit to the CIA, but Bitcoin is a lot bigger than when I visited the CIA...

Anyway, here's the invitation I received:

Quote
On behalf of the Council on Foreign Relations (CFR), I write to invite you to speak to our Washington-based members as part of our Voices of the Next Generation series. This program seeks to bring together our members with fresh, young voices in the nation’s foreign policy discourse. Given your work with BitCoin, you would be an important addition to the series. In the past, the Voices of the Next Generation series has featured Esther Duflo, Abdul Latif Jameel professor of poverty alleviation and development economics, Massachusetts Institute of Technology, Ayman Mohyeldin, Middle East correspondent, Al-Jazeera English, and Jennifer Pahlka, founder and executive director, Code for America.

CFR is a nonpartisan national membership organization and think tank, as well as the publisher of Foreign Affairs. Among our members are many past and present U.S. presidents, secretaries of state, defense, and treasury, as well as other senior U.S. government officials, renowned scholars, and major leaders of American business, media, and nongovernmental groups.

The format of the event will be a 90-minute question&answer session, moderated by somebody yet-to-be-determined. It will be "on the record," meaning press could be invited to attend and recordings and/or transcripts may be posted on CFR's website.

The audience will be CFR members and invited guests (and maybe press); it is not open to the public. I am not getting paid by the CFR.

117  Bitcoin / Bitcoin Discussion / Re: Bitcoin-Qt / bitcoind version 0.8.6 released on: December 09, 2013, 08:36:55 PM
Bah, I forgot to code-sign the Windows .exe. Expect an updated .exe and SHASUMS soon.
118  Bitcoin / Project Development / Re: Two-factor authentication on: December 04, 2013, 03:47:40 AM
https://gist.github.com/gavinandresen/5616606 sketches out one way to do it.
119  Economy / Service Discussion / Re: Are there any good bitcoin ponzi schemes starting up? on: November 26, 2013, 02:09:53 AM
You disgust me. Participating in a ponzi is immoral.

You might as well ask "Anybody know some good scams I can make money from?"

Do something productive that makes the world a better place instead.
120  Bitcoin / Mining / Re: Pools please rais blocksize limit! on: November 22, 2013, 12:57:52 AM
It looks like maybe some pools have reacted; the average block size is going up:
  http://www.quandl.com/BCHAIN-Blockchain/AVBLS-Bitcoin-Average-Block-Size

For those that haven't, the relevant bitcoind command-line arguments are:

Code:
-blockminsize=<n>      Set minimum block size in bytes (default: 0)
 -blockmaxsize=<n>     Set maximum block size in bytes (default: 250000)
 -blockprioritysize=<n> Set maximum size of high-priority/low-fee transactions in bytes (default: 27000)
 -mintxfee=<m.n>        Minimum  fee-per-kilobyte to qualify as fee-paying (default: 0.0001)

Adding:
Code:
blockmaxsize=500000
blockprioritysize=45000
... to your bitcoin.conf and re-starting bitcoind (or running with the command-line arguments) will really help with the transaction crunch.

I'm still hard at work (nearly done!) on making the reference implementation much smarter about transaction fees, but until wallet software gets smarter about fees we need to rely on big pools doing the right thing so Bitcoin users don't get frustrated by long transaction confirmation times.
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 ... 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!