Zarutian wrote a proposed Bitcoin URI scheme for this kind of thing, and I made some modifications. Here it is: http://pastebin.com/VsBbmXQxAccording to that, you would use something like: x-btc:addr=1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD?theymos;store This says "Store 1NX... in your address book under the label 'theymos'". |
|
|
|
|
The fix, for those interested: if any change would be less than 0.01, it is "thrown away" by adding it as a transaction fee. Someone else will get it when they generate a block. Maybe someone will manage to collect enough of them to form a usable cent.
|
|
|
|
So I lost a penny in it. My question then, that transaction fee, then goes to the next block? Or the one before the one I generated?
You didn't pay a transaction fee. You have .01000010 in your balance; you just can't spend it. The network would accept it if you sent the entire 0.01000010 to another address (you can't break it apart), but the Bitcoin interface doesn't support such high precision. Since fees apply to transactions less than 0.01, adding a transaction fee should be at least 0.01 right? That's not network-enforced. Transaction fees are not "outs", so they're not subject to the "dust spam" restriction. it seems I paid the fee too. Why would that be? A block that had too many tx, the value coming from multiple small value purses (but the client should see one purse that satisfies the whole transaction, right?) or what else?
You received a fee of 0.01. You didn't pay one. |
|
|
|
|
0.3.12 contains some changes to transaction fees. Are you using that?
|
|
|
|
|
If you send your entire balance, then you won't have enough left to pay any fee. You could send 49.99.
I don't know why that's happening. There shouldn't be a fee for any non-combined transaction.
|
|
|
|
sudo ssh -ND 443 <my server's hostname>@<my ip address>
sudo ssh -ND 9999 <my server's hostname>@<my ip address> You would run these commands with the SSH on the non-server computer. Then you'd connect to localhost:443 or localhost:9999 with SOCKS. Also, it's remoteUsername@remoteIP; you're connecting to the user at the IP. You could use antinat to set up a SOCKS server on your server. Then you wouldn't have to run SSH on the non-server computer. |
|
|
|
Won't older clients will reject non-standard transactions, even if newer [future] clients are updated to generate them?
They just won't include them in blocks they generate. So the transactions might be slowed down a bit, but not stopped entirely. |
|
|
|
What does the prohibition of "nonstandard" transactions do? main.cpp:506
// Rather not work on nonstandard transactions
if (GetSigOpCount() > 2 || ::GetSerializeSize(*this, SER_NETWORK) < 100)
return error("AcceptToMemoryPool() : nonstandard transaction"); What is included in "GetSigOpCount", and what does "GetSerializeSize" measure? This is "lightly" enforced by the network: main.cpp:1425
// Check that it's not full of nonstandard transactions
if (nHeight > 79400 && GetSigOpCount() > MAX_BLOCK_SIGOPS)
return error("AcceptBlock() : too many nonstandard transactions"); |
|
|
|
|
The GPL doesn't force you to release your source if you don't publish the software publicly. Even the AGPL wouldn't force you to release the source in this case, since you're not really allowing people to interface with your software.
MIT-style licensing is the only way to ensure widespread adoption. Companies won't touch GPLed software.
|
|
|
|
I was wrong about this. Even though transactions to yourself are displayed differently, it appears like a normal transaction in the block. "out" : [
{
"value" : "0.24000000",
"scriptPubKey" : "OP_DUP OP_HASH160 0x4434DD10F5392C1F080B83
92D3135D0D13670400 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value" : "51.13000000",
"scriptPubKey" : "OP_DUP OP_HASH160 0x98352ACB25A13F646AB75D
825B1B8911341BAE14 OP_EQUALVERIFY OP_CHECKSIG"
}
]  To determine that the payment is from yourself, Bitcoin just checks to see if all of the receiving addresses and all of sending addresses are in your wallet. if (fAllFromMe && fAllToMe)
{
// Payment to self
int64 nValue = wtx.vout[0].nValue;
InsertLine(fNew, nIndex, hash, strSort,
strStatus,
nTime ? DateTimeStr(nTime) : "",
_("Payment to yourself"),
"",
"");
/// issue: can't tell which is the payment and which is the change anymore
// FormatMoney(nNet - nValue, true),
// FormatMoney(nValue, true));
} |
|
|
|
|
PeerBlock is useless. Every entry in the blocklist is based entirely on rumor and paranoia. Large sections of AT&T and Comcast are blocked, which prevents you from communicating with many typical consumers. BlueTack (the provider of PeerBlock and PeerGuardian blocklists) once accidentally blocked its own server; they are totally incompetent. Using a blocklist that randomly blocks half of all IP addresses would be safer.
Everything should work as long as PeerBlock doesn't lie (silently block data) when it blocks a connection. Bitcoin will try other addresses.
|
|
|
|
Could this be distributed somehow? You could jumble the coins into different sized chunks and recall them as needed in some randomn way? I can't think of any way to remain strongly anonymous in any e-currency system and not trust someone. You can send bitcoins to new addresses owned by yourself in random intervals and amounts. This frustrates attempts to identify you, but I don't think it'd be sufficient to stop a determined attacker. Using the current code to send bitcoins to yourself (the same client) is useless, though, because Bitcoin makes a special, obvious transaction when you do that. There are some interesting things you can do with the "external mixing service" concept. You can probably chain multiple mixers while only trusting one of them not to steal your bitcoins. You still need to trust one person, though. Bitcoin-backed "bank notes" transmitted with a strongly anonymous but centralized system like Open Transactions is probably the best solution. |
|
|
|
What if you set up a separate laundry node behind tor and sent all the coins to it from the public laundry service? Would your coins be traceable when sent to someone else ? Bitcoin needs its own onion routing scheme  With Bitcoin, Tor doesn't help much. Read this: http://www.bitcoin.org/wiki/doku.php?id=anonymityAt the end of that article I described a somewhat easy-to-implement "Bitcoin laundering" service: - Set up two Bitcoin installations.
- Put some amount of BTC in installation B. This is the maximum amount of BTC you can deal with at once (for all customers).
- Customers send BTC to installation A. You send them an equal number of coins (or minus a fee) from installation B. Send as 10-50 BTC increments.
- Send all coins from A to B when all orders are satisfied. You can't send coins from A to B if you have any orders that have not been satisfied from B.
- This can be automated, or you can do everything manually. This still keeps logs (unavoidable without modifying Bitcoin), but it ensures that you never get back your own coins. The log situation can be helped by periodically moving your bitcoins and deleting the empty wallet.dat file (this deletes all of your receiving addresses, so be careful). |
|
|
|
|
Alerts are broadcast in the same way as transactions. Each node, upon accepting the alert, sends the alert to all of its peers.
Bitcoin won't relay alerts that are signed with a different key. Propagation might not be very good for any client if different alert keys start being used.
|
|
|
|
Do they delete all logs on send?
You're not actually deleting logs unless you've modified Bitcoin. Bitcoin keeps logs of every transaction in wallet.dat. |
|
|
|
|
It's better to use MyBitcoin for this. MyBitcoin has more bitcoins "in circulation", so you are much more likely to send coins that didn't belong to you. With BitLaundry, you'll probably end up sending mostly your own coins. Also, unless you've modified Bitcoin, logs of every transaction are still kept.
|
|
|
|
The difficulty can't increase or decrease by more than a factor of four in a single retarget: // Limit adjustment step
int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
printf(" nActualTimespan = %"PRI64d" before bounds\n", nActualTimespan);
if (nActualTimespan < nTargetTimespan/4)
nActualTimespan = nTargetTimespan/4;
if (nActualTimespan > nTargetTimespan*4)
nActualTimespan = nTargetTimespan*4; Total network power right now is nearly 5 billion hashes per second. So total network power, in hash/sec, is then
(difficulty * 2^32) / 600
Where 600 is a smoothed approximation of last-block-interval-in-seconds.
|
|
|
|
Any ideas on proper or best method to "fix" this? I am not so knowledgeable of copyright.
Including "Copyright 1999-2010 Gentoo Foundation" didn't assign your copyright to the Gentoo Foundation. Looking at this, you can just remove the header (and the other comments if they're copied). It's pretty generic stuff. If the work is not derivative, there's no legal risk in placing it under another license or even keeping full copyright. Old code will still be usable under the GPL, but new code will be under the new license only (you aren't required to put it under the GPL if you're the sole copyright holder). For a derivative work, you would change the header to something like this: # Copyright 2010 mizerydearia
# Distributed under the terms of the GNU General Public License v2
# Based on the ebuild for LightBlue:
# /var/cvsroot/gentoo-x86/app-mobilephone/lightblue/lightblue-0.4.ebuild,v 1.3 2010/03/27 17:57:36 arfrever Exp
# Copyright 1999-2010 Gentoo Foundation I don't think it is derivative, though, if you remove the header. (IANAL) |
|
|
|
You have to modify your client to make a higher-precision transaction like this, but the change isn't difficult. It's not a problem. I'd be surprised if this hasn't been done before. CTransaction(hash=65c356, ver=1, vin.size=1, vout.size=2, nLockTime=0)
CTxIn(COutPoint(893335, 0), scriptSig=0x01B8C315FD58F0DFA0DEA2)
CTxOut(nValue=1.85850000, scriptPubKey=OP_DUP OP_HASH160 0x3181)
CTxOut(nValue=3.14150000, scriptPubKey=OP_DUP OP_HASH160 0xF99E) |
|
|
|
|
Show Posts
