Bitcoin Forum
November 19, 2024, 06:10:07 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 »
1381  Bitcoin / Development & Technical Discussion / Re: Configurable transaction fees on: May 05, 2011, 03:09:38 PM
Half-baked thoughts:

Broadcasting policies makes me nervous-- it is too easy to lie, and there might be some advantage to lying.

Couldn't clients infer all the information they need to know about what transactions/fees are being accepted by miners by keeping track of transactions in the memory pool and looking at the last 10,000-or-so generated blocks?
1382  Bitcoin / Bitcoin Discussion / Re: Let's add up the KNOWN lost bitcoins on: May 05, 2011, 02:28:13 PM
Block 70136 has 0.03BTC in un-spendable transactions.

9050+
     0.03
---------
9050.03
1383  Bitcoin / Bitcoin Discussion / Re: Maybe Gavin could speak at TED on: May 05, 2011, 02:03:10 PM
TED is about "the vision thing"; somebody really good at public speaking and putting together compelling presentations should do it.

Somebody who actually enjoys travelling around and speaking about something they are passionate about.  I want to spend my time building stuff, not talking about stuff.

PS:  I think bitcoin needs another year of growth before it is TED-worthy.
1384  Bitcoin / Development & Technical Discussion / Re: Why Don't "We" Pay Our Bitcoin Client Coders In BTC? on: May 05, 2011, 12:15:27 PM
The project needs more bug fixing and testing, so I would rather NOT see bounties for new features.

Bounties for fixing bugs would be ok.  And maybe a bug bounty, for finding significant bugs.
1385  Bitcoin / Bitcoin Discussion / Re: Suport Bitcoin currency code BTC in ISO 4217 on: May 05, 2011, 11:59:02 AM
In order to get the Bitcoin currency code BTC more widely supported, forget about ISO. Just use the code.

+1
1386  Bitcoin / Project Development / Anybody in/near Chicago interested in giving a presentation? on: May 04, 2011, 08:25:02 PM
Quote
If someone from your team is ever in the Chicago area, I would love to schedule a presentation at The University of Chicago, Innovation Roundtable.
So, team:  anybody interested?
1387  Bitcoin / Development & Technical Discussion / Re: Method of supporting a "return address"? on: May 04, 2011, 05:39:17 PM
I was actually thinking a return address would be a good use for the arbitrary-message-to-receiver OP_DROP transaction type.

Maybe make a convention that bytes be a JSON dictionary, so it could be:

{'return_address':'n2cGZYsiii1uAiDPM6ipPBqqXa4Z9bXh2t'} OP_DROP ...etc...

... which would be inefficient (58 bytes to encode the 20-byte return address) but wonderfully extensible.

And again:  I'd like to see experimentation on testnet.
1388  Bitcoin / Bitcoin Technical Support / Re: Lost .00000001 of a bitcoin on: May 04, 2011, 12:41:36 PM
Does it check to see if it could add another input in order to avoid throwing money away in a fee, or does it just look for the first input that fits, and it's just too bad if it's less than 0.01 more than the amount of the transaction?

The latest version of bitcoin does try to avoid "sub-cent change" by adding more inputs.

If it can't avoid it (e.g. you have 32.29 in your wallet and you send 32.28999999), then the sub-cent change becomes a sub-cent transaction fee.  It isn't lost, the miner that includes the transaction will get it.
1389  Bitcoin / Bitcoin Technical Support / Re: Confused by automatic addition of tx fees by sendmany on: May 04, 2011, 04:03:41 AM
bitcoind doesn't prompt before adding fees because it is meant to be used by websites and other services where there may not be a person available to push an "Ok, pay a fee" button.  There might not even be a place to put the button, either.

Your Transaction 2 paid a fee because it ran into the "small, low-priority transactions must pay" code that is new with version 0.3.21.  It was low priority because its outputs were small and its input was fairly new.
1390  Bitcoin / Bitcoin Discussion / Re: Anyone know what happened to knightmb and his 371,000 BTC? on: May 04, 2011, 12:07:15 AM
When you go to the bank and get your CD-R and set the wallet up again, all your bitcoins that you sent to that wallet will magically appear.
you have to use -rescan for the magic to work, though, afaik.

Bitcoin 0.3.21 puts a 'bestblock' entry in the wallet so it will automatically -rescan if you restore an old wallet (and it only rescans the blocks necessary to get up-to-date).
1391  Bitcoin / Development & Technical Discussion / Re: Untraceable transactions which can contain a secure message are inevitable. on: May 03, 2011, 11:52:34 PM
RE: agreed upon spot to place or distribute messages:

I think it is time to start experimenting with a <bytes> OP_DROP OP_DUP OP_HASH160 ...etc transaction type on the testnet.

And time to finish implementing headers-only-for-initial-download mode so new users don't have to wait so long to get their free Faucet bitcoins.
1392  Bitcoin / Development & Technical Discussion / Re: [PULL] Sign and verify message with bitcoin address and public key on: May 03, 2011, 11:37:29 PM
That said, there is never anything wrong with adding just a bit more salt to your hashes.
You're suggesting:
ECDSA_SIGN(SHA256(RIPEMD160(SHA256(public_key))+"fixed string"+message))
 is more secure than:
ECDSA_SIGN(SHA256("fixed string"+message))

It sure looks more secure!  But maybe some super-smart cryptographer will tease out a relationship between all the hashing and signing in the first version and it will turn out to be less secure; maybe she'll figure out a way to factor out the private key if the public key is involved in the salt.

I like the simpler version better.
1393  Bitcoin / Development & Technical Discussion / Re: Stopping an attacker who has >50% of the hashing power on: May 03, 2011, 11:12:53 PM
Neat idea!

I don't like the economics of it, though.

First, it reinforces the "if you started mining early you are rich only because you were lucky enough to be early" idea.  And a lot of people already think that is unfair; give the early miners a current mining discount and you're just "helping the rich get richer."

Second, what stops an attacker from offering early miners $$$ for their (already spent) coinbase private keys?  If they have value because they give a mining discount, then there WILL be a market for them.  A wealthy attacker could just buy up as many as they can find and then take over the network with less hashing power...

1394  Bitcoin / Development & Technical Discussion / Re: [PULL] dns lookups for -addnode and -connect on: May 03, 2011, 12:54:15 PM
I actually think it is useful. It would be even more useful to allow most of these options configurable through the config file.

All command-line options (except for -datadir and -conf) can be specified in the config file.
1395  Bitcoin / Project Development / Bitcoin Faucet Community Policing Project on: May 02, 2011, 05:47:14 PM
I launched a new version of the Bitcoin Faucet today, with a few changes:

1. Payout is now 0.02 bitcoins (down from 0.05), to reflect the rise in value of bitcoins versus other currencies.

2. Recent Sends page, showing scrambled email addresses and (not scrambled) IP addresses of the last 100 people to get coins from the Faucet.

3. Behind the scenes, faucet payouts are bundled up and sent in batches every N minutes, to minimize the fees that the Faucet pays.

I want to recruit some trusted volunteers to be "Faucet Police" -- if somebody notices a fishy pattern of either IP addresses or email addresses, I'll give the Faucet Police the ability to temporarily stop the flow of coins from the Faucet.

If you're willing to help out and you've got a good reputation/history here on the forums, email me (gavinandresen@gmail.com) your google account information along with what time zone you're usually in, and I'll try to pick a couple handfuls of people so no matter what time of day or night, somebody will be awake and ready to turn off the spigot.
1396  Bitcoin / Development & Technical Discussion / Re: transaction fees and negative balances on: May 01, 2011, 05:55:09 PM
"you didn't offer a fee" is misleading; the bitcoin software 99+% of people are using today doesn't let "you" very much flexibility in how you offer fees.  So basically, 99+% of people using bitcoin are charged fees based on a set of built-in rules.

If you want to send a fee with every transaction, you can run bitcoin with the -paytxfee= option; there isn't much reason to do that now, unless you're generating lots of very small (few-bitpenny) transactions.  The Bitcoin Faucet is running with -paytxfee=0.01 because it DOES generate lots of very small transactions.

From the wiki:
Quote
Current "Default" Rules for the regular Bitcoin client (Bitcoin 0.3.20)
0.01 BTC fee if sending any transaction less than 0.01 BTC. This is to help prevent DoS attacks against the network. Remember: fees are not network-enforced, so it's still possible to send these small transactions without the fee -- you just have to generate the blocks that contain them yourself (after modifying Bitcoin).
0.01 BTC fee per kilobyte of transaction, but:
If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.
If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.
Transactions within each fee tier are prioritized based on several factors. Most importantly, a transaction has more priority if the coins it is using have a lot of confirmations. Someone spamming the network will almost certainly be re-using the same coins, which will lower the priority of their transactions. Priority is also increased for transactions with more BTC, and reduced for transactions with more data.
If the blocksize is over 4kB, free transactions in the above rules are only allowed if the transaction's priority is above a certain level.
1397  Bitcoin / Bitcoin Technical Support / Re: How do I setup a headless bitcoin server? on: May 01, 2011, 02:14:09 PM
tail -f ~/.bitcoin/debug.log
... will show you what bitcoind is doing.
1398  Bitcoin / Bitcoin Discussion / Re: Video: What Is Bitcoin? from weusecoins.com on: May 01, 2011, 12:22:24 AM
Maybe link to instawallet.org should be added to the getting started page?

Nothing against jav, but I think instawallet needs a month or three of 'soak time' to give the scammers and script kiddies time to try to break it (and to see how jav reacts to the scammers and script kiddies trying to break it...).

1399  Bitcoin / Development & Technical Discussion / Re: Thoughts on making fees for relaying transactions more flexible on: April 30, 2011, 11:14:20 PM
An option to use old coins in priority could avoid the last 2 problems.

The built-in coin selection algorithm already prefers using older coins rather than newer ones.
1400  Bitcoin / Development & Technical Discussion / Re: transaction fees and negative balances on: April 30, 2011, 11:11:52 PM
Uhhh...  maybe a specific example will help.  Lets say you start with accounts/balances of:

A: 5
B: 5
"": 1
Total wallet balance: 11

Now you send 5 BTC from A, and pay a 0.01BTC fee.  Account balances will be:

A: -0.01 BTC
B: 5
"": 1
Total wallet balance: 5.99

The fee isn't 'taken' from either B or "".  You'll have to decide how to handle fees; for ClearCoin, I keep a positive balance in the "" account and automatically move coins from there if a transaction results in a fee (so for the above case, 0.01 bitcoins would be moved from the "" account to A, so A ended up with a zero balance and the fee is paid from "").

Pages: « 1 ... 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 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!