Sorry, sorry
that my English, German and other language abilities are'nt just as perfect as dead certainly yours.
Is somehow new for me however, that imperfect use of a foreign language might be an argument.
Anyway. That seems to be the best argument to ignore arguments.
Perhaps I will use this nice feature myself in the future.
What about their authors German or Spanish abilities?
Oh, no, no. You don't get to pull this shit. Your ideas are nonsense because you don't have a clue what bitcoin is. This is clearly and extensively documented in the thread I linked. We spent days trying to teach you about bitcoin. The problem is not your imperfect command of English. The problem is you. I'm not going to waste yet more time explaining what is wrong with your alleged ideas. Refer back to the other thread to see why. |
|
|
|
I normally try really hard to understand posts when it appears that the author isn't a native English speaker, so I read this whole thing four or five times, and I still can't... Hey, wait a minute! Are you the same LvM from the binary map thread that was saying that there were no logical differences between bitcoin and other currencies? I hope that the other posts in this thread have led you to do some research into what exactly a cryptocurrency is, and how it differs from a bank ledger. Bitcoin is not just the same money that you know about under a different name. It is something new. Well, new-ish.
I assure you that you are not the first person to suggest a scheme of balance tracking. Hell, you probably aren't even in the first thousand. Feel free to augment your research into cryptocurrencies by looking into why no such proposals have gone anywhere. Hint: It isn't because we are all just too stupid to see your brilliance. |
|
|
|
My understanding is that miners take the first transaction they receive, and henceforth throw out any conflicting transaction received after that one. What does this mean? If my transaction propagated throughout 90% of the network, a fraudster would need to either convince the miners to dump that transaction and take a new one (the double spend) or to transmit the new double spend transaction to the remaining 10% and hope they will find the next block.
Virtually all of this is assumption. No one can force miners to pick one transaction over another for inclusion in a block. No one can force nodes to relay one transaction over another. We think that your assumptions are mostly correct, for now. But nothing is sure until it is confirmed. Rely on good intentions at your own peril. Different people in different situations will have different levels of acceptable peril. |
|
|
|
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -1002,7 +1002,7 @@ bool GetTransaction(const uint256 &hash, CTransaction &txOut, uint256 &hashBlock
if (view.GetCoins(hash, coins))
nHeight = coins.nHeight;
}
- if (nHeight > 0)
+ if (nHeight >= 0)
pindexSlow = FindBlockByHeight(nHeight);
}
}
Just FYI, this is a dangerous patch and should not be used. The genesis generation should not be in your index. If it is in your index, your node is vulnerable to a fork attack. An extremely unlikely fork, to be sure, but a hard one. If you really need the information from that block, you should get it out-of-band, not from your client. |
|
|
|
|
No.
You can only do this with raw transactions. Using the friendly functions, you get no control over the change address.
|
|
|
|
|
The 8.2 release candidates include a -walletnotify option that can run a process when a transaction that affects the wallet is seen. It would be fairly simple to write a script for that to call curl or wget to create a HTTP callback.
If your bitcoind is busy (or will be some day), or if the callback server is unreliable, it would be wiser to do it in two stages. The -walletnotify could drop an entry into a database, and a second process could read those entries and execute the calls. The reason is that the -walletnotify process needs to return promptly to avoid runaway processes.
|
|
|
|
* Once upon a time, it was possible to create identical chains of transactions.
Wow, got a link to this? Not off the top of my head, but look for the discussion around BIP 34. The whole point of adding the height to the coinbase was the make each generate transaction unique. Prior to that, it was possible to create duplicates. And since duplicate generations would have identical hashes, you could, in theory, make a chain of transactions starting from one generate, and then duplicate the entire chain later. It would be difficult to trick someone using this quirk, but not impossible. Also, it was ugly. Which is why it got fixed. |
|
|
|
|
There are no addresses.
A transaction is just two lists. The first list is a list of past transactions that are being redeemed (the inputs), the second list is a set of outputs and the conditions necessary to redeem them in the future. In a standard transaction, the redemption conditions are constructed from the address.
The input list is composed of {txhash,seq} pairs. The txhash is the hash of the transaction, and seq is the position in the list. txhashes are unique (with a few historic exceptions that users are safe to ignore), so the second transaction to that address will be different from the old one.
|
|
|
|
|
No.*
Transactions involve previous transactions. There are no accounts, no addresses, no balances.
* Once upon a time, it was possible to create identical chains of transactions. The door has been closed, and if I recall correctly, it was never used for evil.
|
|
|
|
|
I think that schemes like this are doomed to failure.
Right now, a bitcoin transaction has very simple rules. There are really only two:
A transaction is valid if it satisfies the conditions specified in the inputs it redeems.
A transaction output can only be redeemed once.
That's really all there is to it. A powerful and useful system defined by just two simple rules. The pinnacle of engineering and beauty, nothing left to take away.
Now, our computers are really dumb, so things that we take for granted, we have to explain to them in great detail. So, the software isn't as beautiful as the idea it represents. We have to tell the computer that you can't have a negative output to balance out a too-large output, and things like that.
Assume that we devise some way to allow the network to take action against double spends. There are horrifying technical challenges in that task, but we are going to assume that condition, so we don't have to worry about solving them. Any such scheme is going to destroy the beauty of the system. There won't be two simple rules that you can explain to literally anyone in 5 minutes, there are going to be three. And the third one is going to be ugly. It is going to start out with "Except when..."
The first rule is math. The second rule is time. Both of these are necessary, in that you can't have a system like this without math and time. The third rule will be the mob. The third rule will be the one that we added to make some particular group of people happy. The third rule will be the foot in the door for the fourth rule, to make some other group happy. And then the fifth. Next thing you know, we'll have a group of people meeting on an island to add a rule that will solve the world's problems.
Fortunately, I think that people see this. Even if we could distill the problem down to "just a bit of code", it would destroy the beauty of the system. The software could take the hit, lot of it is already ugly. But it would be fatal to the idea that the software represents.
|
|
|
|
|
The real story is reporters fooling you into believing things that aren't true. In this case, the lie is that there was some tax that should have been paid, in addition to all of the actual real taxes that they did pay.
|
|
|
|
|
This debate is silly, as well as off topic.
There is no such thing as allodial title in the modern world. All property is community consensus, but one with the rules (mostly) already spelled out.
|
|
|
|
Is it conceivable that a judge could conclude that because the miner was running this replace-by-fee code and received compensation for doing this that the miner could liable for losses by the merchant? [Edit: or charged as an accessory to the crime of fraud even?]
Sure. But it would be silly to do so. The blockchain is what defines the order that transactions happen. If a miner can be liable for replacing a transaction, why not for failing to replace it? The network makes no promises to deliver transactions to nodes in some magically special order, except when that delivery is as a block. What if the miner gets the replacement first? How do you prove otherwise? Judges, in general, aren't stupid, and this is simple stuff, easily explained. |
|
|
|
|
Basically, you don't understand how mining works.
The pool gives work to your miner. That work is in the form of a block header, and it is specific to that pool: the associated block pays the pool. Your miners work on that header, and any hashes found that meet the pool's criteria for being a share are sent back and used to calculate your speed and credit your account.
You can't send the same work to multiple pools, because only one of them will recognize it as being one of their blocks. The pool is not giving you "worthless work" to do for shares, you are doing the actual work and looking for the actual block.
A "share" is just a header hash that meets the pool's share criteria, which may or may not meet the network's block criteria.
|
|
|
|
|
DDOS? zero. There is no amplification, no redirection.
Someone can try to DOS you. But it'll be expensive. Your node will spawn a process for each transaction that hits your wallet, not for each output. You should strive to make the spawned process as light and short lived as possible, but for the most part, there isn't much danger.
|
|
|
|
And moreover, it creates a lot of hassle, forcing you to backup your wallet after every payment.
It most certainly does not. indeed, it does not. but how is a simple user supposed to know when there was a new address generated for a change, so he should make a new backup? there is no such indication - so basically, if you don't want to loose any money, you should do a backup after every send. |
|
|
|
Coins are not stored on your computer, or in your wallet. If the transaction actually happened in the public block chain, it doesn't matter what software you are using to see it.
You just need to make sure that you still have the wallet.dat that contains the key to the address you sent to.
Thanks, but what would cause the newest version to be synched with the network and not show my coins when the old version still is catching up? I'm guessing once the old version catches up enough I will see my coins. I'm just worried the 5-15 deadline might mess things up. Still 20 days of catch up to go on the old version before I should see my coins. I also want to add the new version also had the address I sent the coin too listed under receive coins. Anyone know what could be the issue here? I might be on a very short amount of time to act before I lose my coin due to the deadline. I'm trying to tell you that the deadline has nothing to do with this. It has zero effect on transactions. It won't cause you to lose anything. What I'd like to know is, how many wallet.dat files do you have, and which one has the key to the address that you sent your coins to? If the new version showed that address under Received, then it should have that transaction. Check one of the public blockchain websites (blockexporer.com, blockchain.info, etc). Just search for that address and see if you can find that transaction. If the transaction shows up there, but not in your client, then you may need to stop and start again with -rescan. If you are willing to post the transaction hash or the address involved, someone can try to look it up for you if you aren't familiar with searching those sites. |
|
|
|
|
This sounds like a great question... to ask the people that run that website.
|
|
|
|
|
Show Posts
