|
We use it for ECDSA signing and verification, to generate private keys, for the SHA256 and RIPEMD160 hashing functions. and for AES (used in wallet encryption).
|
|
|
|
|
This requires an index (from addresses to all transactions that affect it) which isn't necessary for normal operation.
It's currently not implemented, but adding it wouldn't be that hard. It's not a priority, though.
|
|
|
|
|
How about allowing the totally optional string "bitcoin:" before an address?
|
|
|
|
Simply eliminate the bytes belonging to the signature field from comparison. Adding a signature, according to a cursory Google search, simply fills in a pre-allocated signature field inside the executable in a location that can be found deterministically from the executable file headers. When Microsoft hashes the file for the purpose of signature validation, this field is located and excluded from the hash calculation by design, so a signed binary will hash the same as an unsigned one for their signing purposes. The build process could do the same. Then it could automatically confirm that the same binary (minus the signature) was signed by everyone, and then you'd have great security.
Sounds like it's relatively easy to add/remove such a signature from a binary, so it could be done after the gitian building step, and still be verifiable. I'm all in favor of signing released binaries if it helps making Bitcoin trustworthy. I'm totally oblivious about the process to achieve that for Windows binaries, though. |
|
|
|
If instant transfers are so demanded, there will be centralised services like vouchers from exchanges or account-to-account transfers.
There is nothing wrong with accepting zero-confirm transaction IF the receiver is aware of the risk; and many probably underestimate those... My preferred solution is still a third party that insures against double-spends or otherwise invalid payments. |
|
|
|
(Note that I had to assume that the last output from a transaction is the change).
That assumption will be wrong 50% of the time... |
|
|
|
|
The accounts/labels in the (non-raw) bitcoin API do not have anything to do with coin selection. It's simply in order to keep separate balances for accounts in a shared wallet. The actual coins are shared, but transactions to certain addresses will credit the account they belong to, and sendfrom will deduct its balance from the given account.
If you need control over the coin selection process, use the raw transaction API, or separate wallets (zhich is, right now, mostly a pain, but we at least plan to add support for multiple wallets in some future version).
|
|
|
|
|
For something to be a store of value, it needs to have value.
I'm sure that without trading, exchange rate would drop very quickly...
|
|
|
|
|
I think in the future that even people using the Bitcoin protocol directly will not frequently pay fees.
When paying a merchant, you send the transaction to them, they combine it with a spending a transaction to secure it (which does carry a fee), and broadcast them both on the network. A fee is paid for the original payment, but the customer doesn't see it.
Another solution is a payment protocol which negotiates transactions with the receiver before broadcasting them, allowing the receiver to refund a fee. For example: you want to send 10 BTC somewhere, and you create a transaction that sends 9.9995 BTC to the merchant's address, and 0.0005 as fee. The client software transparently shows it as a 10 BTC transaction, however. This is quite close to how electronic payment systems work now (the receiver pays for the service).
Nonetheless, both solutions above are ways for shifting the fee to the receiver - it doesn't remove it. But that's not really possible in general: Bitcoin is an expensive beast to maintain, and people working to secure it (and maintain it, ideally) need some financial incentive to do so. This is not very different from other currencies, where inflation and taxation can be seen as payment for the service - only it's invisible to the user, as it probably should be in our case as well.
|
|
|
|
|
Currently bitcoin transactions are just transfers of money. They are not "payments", as there is no indication for example what the transfer is for, who sends it, or how it can be returned. In particular, there is no indication that the transfer was requested by the receiver.
Receiving an involuntary bitcoin transaction is like finding a bar of gold on your doorstep, and potentially later realizing it was stolen good.
As in so many cases, the solution in my opinion is a payment protocol, where the transaction can be negotiated by sender and receiver at the exact time when the transaction takes place. Regardless of whether marking coins tainted (even subjectively) is a good idea, such a system would certainly allow transactions to be refused.
|
|
|
|
|
bitcoind can function either as P2P node + RPC server, or as RPC client.
If you run "bitcoind help", you send the RPC command "help" to the RPC server, and get as response the supported RPC commands by that server.
If you run "bitcoind --help", you get information about the command-line options supported by the actual binary you are running.
|
|
|
|
We updated today from 6020 to 70003 all went smooth, thank you very much!
One thing we can't figure out. Why bitcoind API can't return the senders address from a transaction?
We are still using third parties for this operation which is far from optimal. I believe that lot of others have the same needs as I read in other posts.
Bitcoin transactions do not have a sender address. They have one or more input txouts, each of which may or may not have an identifiable address it was previously sent to. Relying on this information is not portable, as it is client-dependent. If you need a refund address or some payout address, ask for it. This also prevents reuse of addresses, which is bad for Bitcoin's privacy model (not just of those whose addresses are involved). PS: since 0.7, you can find this information using the raw transaction API. |
|
|
|
|
Note that the reference client does allow you to spend change immediately (without confirmations), while Multibit doesn't (afaik).
|
|
|
|
Always. 30 minutes after startup was same thing.
And earlier versions didn't have this problem? |
|
|
|
|
The bitcoind executable is in the daemon directory. cd there first.
|
|
|
|
|
I believe that as long as no k value in the ECDSA process signing is reused, having multiple signatures to observe should not make it easier to break the security. If that were possible, it would constitute a weakness in the algorithm.
I'm not cryptographer though.
|
|
|
|
Regarding the IPv6 RPC issue, can you guys test whether pull request #1822 fixes the problem? I can create a build of that, if necessary. |
|
|
|
|
Yes, transaction inputs always spend one previous transaction output completely.
Change addresses is something that doesn't exist at the protocol level (arguably, even addresses don't). it's just an artefact of how wallets work.
If you use the raw transaction API, you can implement wallets that work any way you like - including ones that return change back to the original output address. In general, this is not a good idea in my opinion, as it decreases privacy (it makes it obvious which output is change and which is real payment) and encourages address reuse, but it may come in handy in certain situations.
|
|
|
|
|
Bitcoin internally doesn't track addresses and doesn't have any concept of balances.
All there is, is a set of transaction outputs that can still be spent. Using a database that just keeps these is perfectly possible ("pruning") and may soon become how the reference client works.
|
|
|
|
|
Show Posts
