|
By running bitcoind or bitcoin-qt you are running a full node. A full node means that it will fully validate every single block and transaction and block it receives before relaying then to its peers. In order to fully validate everything, it needs the entire blockchain since everything is chained together and to previous history. You can use bitcoin-cli to connect to bitcoind to operate the wallet from the command line or you can use bitcoin-qt to use the wallet from a gui. Either way you are running a full node.
|
|
|
|
None of these methods are even remotely good at determining potential ban evasion in process.
1. IP bans are blast from the past, IPs are expendable and you can have unlimited number of them.
2. Method number 2 offers not enough proof and it is not definitive - it is pure speculation, furthermore I don't believe that we can have bot/script doing this.
3. Potentially the best out of these 3. But still not ideal and could be abused, can backfire and it is just be not accurate to the point you could ban people after comparing addresses.
But these are pretty much the only methods, mostly the third one, that are used to determine alts. If you can think of anything better go for it. This also illustrates how you can't possibly prevent people from evading bans, there simply aren't any truly effective methods of determining alts. BTW the third method checks to see if two addresses posted by to different accounts were used in the sand transaction thus mostly proving that they are the same person since usually only the only time two addresses a can sign a transaction is if the same person owns both private keys. The way around this is to use coin join transactions. |
|
|
|
Bitcoin transaction to my knowledge there is no limit.
Maybe it was just the issue that has not been accurately
Yeah. I think that there is a limit, but it is very high. If I am wrong please tell me. This is what I have heard, I may be wrong. Limit to what part of transactions? Confirmation speed? Transaction size? Please specify. |
|
|
|
Also, MY LAST QUESTION: If BitCoin was designed to be decentralized, why isn't SHA256(Fucke)d Removed
What is wrong with sha256d? How does that break decentralization? |
|
|
|
It will still work, you just need to have the daemon enabled in the config file. Just add To your bitcoin.conf file. |
|
|
|
|
Can you provide the Debug.log file for us to look at?
|
|
|
|
I'm not sure I understand you both. Knightdk, correct me if I'm wrong but I think you may have meant to say that even if a legitimate transaction is broadcast, because of the possibility of a bad transaction within that same block there is no guarantee the block will confirm and thus become irreversible. Franky1, I think you may have meant to say that many people can still mess around with their own transactions and cause issues within their blocks, thus causing them to be orphaned. But as I understand it, should there be a bad transaction, the revised block belonging to the first miner to solve the new hash will be the one used thereafter and the fork will continue from there, orphaning the block with a bad transaction or miner's error. But the legitimate transactions within that orphaned block will surely not destroyed or ignored -- even the slightest practical possibility of such an outcome would invalidate the BTC system completely and it would never have been tried.
Your are wrong. First, a bad transaction would completely invalidate a block, and if that happens then so properly functioning bodes will not remove the UTXOs spent in that block from their UTXO set. Secondly, it is completely possible for a legitimate (meaning valid and confirmable) transaction to not be confirmed. Miners could simply choose not to add a legitimate transaction to a block. If could be because they don't want to, the transaction having a low fee, or having a dust output, among other reasons. All of those simply means that a valid transaction may not be confirmed once it is broadcast. You can be fairly certain if a transaction will confirm by checking a few things, but it is not guaranteed. You can check the fee and for dust outputs, but even if the fee is high and there is no dust, there is nothing that guarantees that it will confirm. All you can say is that it probably will. What I think I am saying is that because an institution will have full control of its own BTC transactions and will ensure that each one obeys the rules, once they are published they are as good as confirmed for the institution's own purposes, and so can immediately be used for a range of internal reasons, including initiating or concluding smart-contracts.
Yes, they could. And actually most clients do just that. Most bitcoin clients will allow you to spend unconfirmed UTXOs if the transaction they come from originated from you because it knows how it made the transaction and it can trust itself to not double spend against itself. |
|
|
|
|
The nSequence field of the input looks like it is 0xffffffff. You will need to change that to something else otherwise the transaction will not be accepted. Resend the transaction but with the proper nSequence.
|
|
|
|
I have updated the site so that some more data is displayed. Notable Changes: - Addresses posted in non-quoted text are now displayed and linked to. If the address was posted multiple times, the first post is linked. The posted addresses are validated before they are displayed
- Information about the next potential rank is displayed.
- Calculation is adjusted down
Edit: Changed to include validation of addresses. add calc change |
|
|
|
Well, it's been up for well over a day now so it appears moving the folder solved the issue. Thanks everyone.  My guess is that there was another computer that was running something (e.g antivirus) on the files in the shared folder which was causing all of your problems. |
|
|
|
Apologies if the following point has already been discussed ad infinitum elsewhere, but I've noticed that whenever I have sent BTC, the transaction has always been published instantly, even though it took a few minutes to actually confirm. If the Bank of America or Visa were to use the BTClockchain for their own internal purposes, they would certainly have procedures in place to prevent their employees from trying to double-spend the BTC sent to addresses to establish transactions. Since such published transactions are sure to be confirmed, shouldn't publication alone be sufficient both for legally accountable record-keeping and to initiate or complete smart contracts? If so, doesn't this mean that, for such uses by such institutions, there is no transaction-time limitation?
No. Even if a transactions is broadcast, there is no guarantee that it will confirm and thus become irreversible. Sometimes transactions have some issues like low fees or dust outputs which prevent that transaction from being confirmed. With the upcoming Opt-In RBF feature, it may not be safe to take unconfirmed transactions if it has opted in to be able to be replaced by another transactions with a higher fee. |
|
|
|
|
You could try purse.io and buy stuff for people to get Bitcoin. They usually have some large premiums though. Another site is VirWox but they have some really high fees.
|
|
|
|
I have already used vanitygen but it does not allow to generate printable wallets with QR-code. This is what is need. Consider it is a little Christmas present and the people which get it, are not really techy, so QR code is necessary;)
Just download the bitaddress.org's source code from https://github.com/pointbiz/bitaddress.org and just open the bitaddress.org.html file in your browser. You can then use it exactly how you would on the website but the website operator cannot steal your keys, especially if you do this on a machine that is not connected to the internet. |
|
|
|
|
That transaction already has 100+ confirmations, so this is a service problem. What exchange are you using? The only thing you can do is contact their support.
|
|
|
|
use only known escrow, because i know in the altcoin era, there were newbie who where offering escrow through another friends, which may appear trustworth at first(because betetr rank and some trust maybe), but they were together there to scam you
How do we define the trusted escrew? How long should they on the market to be trusted? All the escrow service start from 0. There is a list of trusted escrows that are trusted because they have done many trades in the past and have good feedback from those trades. |
|
|
|
Would the blockchain be any lighter if nobody injected shit into it
Yes, but I don't think there is a significant amount of stuff in the blockchain. Probably only a few megs of it. |
|
|
|
|
Most of the paper wallet generators are open source. You can download the source code and run the site yourself to generate your wallet. To be extra secure, you should do this on an offline machine so that even if there is a backdoor, it can't connect to the attacker.
BTW Bitaddress is a trusted site
|
|
|
|
|
This is a service problem with blockchain.info. They have s reputation for having bad service. The only thing you can do is contact their support and switch services.
|
|
|
|
Doesn't Armory count as a full node client?
Not really. It just uses bitcoin core as the verification and networking part. |
|
|
|
There are a few ways you could attempt to prevent ban evasion. I have made a comparison for you. IP Ban: - Pros:
- Cons:
- May ban more than just one user due to shared IPs or dynamic IP addresses
- People can just use proxies and pay the fee
Linguistic Analysis to determine alts - Pros
- Could easily identify potential alts
- Cons
- Could be really hard to program decently well
- Could result in a lot of false positives because people raised in similar environments will typically speak and write the same way
- People who change their writing styles (which is actually a lot harder than you think it would be) would be able to evade this
- Some users might not have enough posts to have enough data to analyze (e.g. newly created accounts)
Blockchain analysis program to determine alts - Pros
- Would be mostly definitive proof of an alt
- Cons
- Might be a little hard to write to have the program distinguish between an address posted by a user and one that a person mentions to talk about something
- Mixers and coinjoin transactions circumvent this
See the problem with all of these is that they cannot prevent and catch all ban evaders. As you said so yourself, if there is a will, there's a way, and those ban evading will find a way to circumvent all of those techniques. |
|
|
|
|
Show Posts
