Explain how this is wrong: every transaction (other than generation-only) includes the public key of the payer (and the ECDSA signature using the corresponding private key of the payer). Payer's public key is thus revealed, and "from" address is simply the RIPEMD-160(SHA-256(PubKey)). Explicit example:  Of course, if there are multiple inputs, there will be multiple "from" addresses. Outputs have scripts, not addresses. And the recognition that transactions have lists of inputs and outputs should give you pause before thinking that you can connect an output to an input, in general. Look at these two transactions, and tell me what the "from" address for each one was. 997e5182...0f463847...P.S. blockexplorer.com having a column titled "From Address" doesn't make it so. And the tooltip note is wrong. |
|
|
|
The short version is that coins don't "come from" anywhere. If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet. But when they came to your wallet, they didn't come from that place.
And that is for simple transactions, it can get worse.
Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work. I think you are taking some metaphors too literally. I think there such thing as "from" address(es), and we can see them for any given transaction. Well, as long as you don't mind being wrong, you are free to keep thinking that.  |
|
|
|
The short version is that coins don't "come from" anywhere. If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet. But when they came to your wallet, they didn't come from that place.
And that is for simple transactions, it can get worse.
Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work. I think you are taking some metaphors too literally. |
|
|
|
|
You can do it without a bitcoind node.
Look up the base58check routines. There are several PHP implementations available. Basically, that is all a bitcoind node would do. (If the address belonged to a known key, it would provide other info too, but that doesn't matter.)
|
|
|
|
I have launched the client with -rescan and now I am able to grab the raw transaction, when I push it with https://blockchain.info/pushtx I get "unable to find all tx inputs" yet it still appear in the client for some reason. Could be. The client doesn't report (or, in general, even know) why a transaction isn't getting confirmations, it just accurately reports zero. You could track down all of the inputs to your 0-conf. One or more of them either has been already used, or wasn't confirmed (perhaps because it wasn't broadcast). |
|
|
|
How is the data transmitted in a decentralized way? Please be as technical as possible. Did you check this page yet? |
|
|
|
You can buy a USB connected laser printer for less than $USD 100. Shop around.
I think mine had a MSRP of like $65 when I got it a few years ago. Cheap ass Samsung USB job. Print density wasn't good enough for direct PCB toner transfer*, but it works great as a low volume home office printer. * For the iron method, the LaserJet 4+ is still king. Absolutely no voids inside sold print areas, so you don't get random breaks in thin traces or pinholes in ground planes. |
|
|
|
Did you check github?
I cannot see anything there before Apr 23, 2011 Odd. I see v0.1.5 and github says it was changed "4 years ago". Bitcoin didn't start in git, but I believe that old versions were all pushed up and tagged a while back, possibly in April of 2011. |
|
|
|
One drawback is that the master block would be huge...
Splitting it in pieces is necessary
Hmm. Maybe we could split the block into a bunch of self-validating pieces. Maybe make each one 1 MB or less. And then we could make a simple P2P network to distribute copies of the pieces as needed. |
|
|
|
|
This is not a change. Zero-confirmations means "not confirmed" today, just like it did yesterday. Confirmations are what make transactions safe. No confirmations, no safety.
Maybe this will finally wake people up. People have been operating for too long under the delusion that their wishes for someone to confirm a transaction someday in the future were equivalent to having trillions of hashes already done in the past.
The sooner everyone accepts reality as it is, the better off we'll all be.
|
|
|
|
|
The short version is that coins don't "come from" anywhere. If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet. But when they came to your wallet, they didn't come from that place.
And that is for simple transactions, it can get worse.
|
|
|
|
The bitcoind wallet is stored in a user specific data directory so you could have multiple user accounts on the same machine. Each one could have their own wallet.
For a second there, I got extremely excited until I saw that it said specific, not specified :-( Damn you for getting my hopes up, but thanks a lot for your suggestion! Well, the user can specify it too. But, it is set when the program is started, and you have to shut down (or run a second instance) if you want to change it. |
|
|
|
* I was thinking of writing a patch to create RPC commands to edit these configuration values without even needing the restart. Some moron claimed that 95% of bitcoin users weren't competent to edit their config file, which I don't in any way believe to be true. Still, adding a RPC command would make it settable by anyone that can find the debug window. It would also allow people to write third party bots to make live adjustments based on whatever data feeds they thought appropriate.
Great idea! I'm sure the solution could (and would) be extended to stream any wallet.dat files found kicking around to a new home pretty quickly. That is a general problem with the RPC system. Sadly, adding a granular permission system to it is beyond what I'm able to tackle right now. Splitting the RPC calls into public, private and trusted, and having distinct credentials for each level would be quite a bit easier, but still not something I have time for.* Also, a script to monitor a few data feeds and calculate appropriate fee levels would be pretty simple. Most people that would actually need such a thing should be able to write their own. * If I were doing it, I would add four new config values, rpcpublicuser, rpcpublicpassword, rpcprivateuser and rpcprivatepassword. The current values (rpcuser and rpcpassword) would be for the trusted account, just like today. Another approach would be to leave the current values as the public info, and make trusted values, but this would break everything. Purely informational calls would require that the user authenticate using any of the three. Calls that could be annoying, but not dangerous, like settxrelayfee, would be public or trusted. Calls that could be dangerous, like sendtoaddress, would require the trusted account. Anyone want a relatively simple project to learn bitcoin development with? |
|
|
|
Cause it was your option to pay the fees, miner still had to include them and relays still had to relay. Was that big of a deal to be honest. This is completely censoring.
I think I've found the problem. You have been operating under the mistaken impression that miners had to include certain transactions, and that nodes had to relay them. No one has ever had to do anything. Miners have always been free to set their own policies for inclusion into blocks, and node operators have always been free to set their own relay policies. This patch makes it vastly easier for miners and node operators to implement their own policy decisions. Calling it "regulation" or "censorship" is somewhere between Orwellian and Kafkaesque. Please don't twist my words, every one else understood what I was saying, and it wasn't what you think I was saying. I am not commenting on this subject anymore cause I realized that people here, take the words from the dev team to heart instead of challenging them on this "temp fix" which I have a feeling will be long term, censorship. It quite sad how many people will skew results, or twist words to fit it to what the dev team is saying including members of the dev team. They should all be ashamed of how they conduct business to the community. I don't see how I've twisted your words. They are plain words, and their common meanings aren't unclear. Before, if you wanted a node with a different mining or relay policy, you had to write your own, or modify the source and recompile. After, you can tweak a setting in your configuration file and restart.* Hardly end of the world stuff, and not in any way deserving of a dozen-thread smear campaign on the forums. P.S. I didn't have to take anyone's word for what the patch does. The source code is public, I just clicked the link and read it. * I was thinking of writing a patch to create RPC commands to edit these configuration values without even needing the restart. Some moron claimed that 95% of bitcoin users weren't competent to edit their config file, which I don't in any way believe to be true. Still, adding a RPC command would make it settable by anyone that can find the debug window. It would also allow people to write third party bots to make live adjustments based on whatever data feeds they thought appropriate. |
|
|
|
|
The bitcoin system has no such concept of a "from address", as has been explained in hundreds of threads.
|
|
|
|
I don't care what you think. This is regulation plain and simple. This is not what I was led to believe bitcoin was. If bitcoin can't handle itself then another coin should take it's place. END OF STORY.
Why didn't you complain when 0.00000000 outputs were made non-standard in the same way some versions ago? Same problem, same reason to make them non-standard. Spendable, but only in theory because it doesn't make sense to pay fees to spend them. You can still send the transactions, and evil miners may mine them just like other dust creating transactions. I don't want them in the blockchain, so I won't help you relaying or mining them. That's my choice. You can't force me to, just as I can't force you to stop behaving badly. Cause it was your option to pay the fees, miner still had to include them and relays still had to relay. Was that big of a deal to be honest. This is completely censoring. I think I've found the problem. You have been operating under the mistaken impression that miners had to include certain transactions, and that nodes had to relay them. No one has ever had to do anything. Miners have always been free to set their own policies for inclusion into blocks, and node operators have always been free to set their own relay policies. This patch makes it vastly easier for miners and node operators to implement their own policy decisions. Calling it "regulation" or "censorship" is somewhere between Orwellian and Kafkaesque. |
|
|
|
|
There is no way to (reliably) predict in advance how much of a fee will be needed. The call would be, at best, a guess.
|
|
|
|
No. You control what you find. But at least you vote with your share of the hash power. If you are using another pool, the pool operator uses your hashpower and votes without asking you.
Then p2pool fixes nothing. Except that p2pool blocks are generated locally. There is no pool operator, just a consensus of what the payout transaction should look like. Each p2pool user can set their own policy, and as long as they agree to pay the other users when they find a block, other users will pay them too. |
|
|
|
|
Show Posts
