Re: Mod, please check new plagiarism: Reporting copy/pasting, please permban
Username : khang minh2
Profile link : https://bitcointalk.org/index.php?action=profile;u=2114685
Can't believe spammer even visit Development & Technical Discussion section now
Copy #1 :
Original #1 :
Copy #2 :
Original 2 :
Copy #3 :
Original #3 :
Profile link : https://bitcointalk.org/index.php?action=profile;u=2114685
Can't believe spammer even visit Development & Technical Discussion section now
Copy #1 :
I don't like the idea of reversing-transaction, but your idea isn't too bad. But i think there are few problems such as :
1. Your idea require new proposal and hard-fork.
2. This can be abused to tricking seller, merchants or the receiver in general.
3. AFAIK, your idea could be achieved similarly with scripting, specifically with HLTC.
1. Your idea require new proposal and hard-fork.
2. This can be abused to tricking seller, merchants or the receiver in general.
3. AFAIK, your idea could be achieved similarly with scripting, specifically with HLTC.
Original #1 :
I don't like the idea of reversing-transaction, but your idea isn't too bad. But i think there are few problems such as :
1. Your idea require new proposal and hard-fork.
2. This can be abused to tricking seller, merchants or the receiver in general.
3. AFAIK, your idea could be achieved similarly with scripting, specifically with HLTC.
4. Increasing node loads since the node need to do extra checking.
5. Even if majority accept the idea, i'm sure the adoption will be very slow and another major chain-split will happen.
6. Your idea is killing zero-confirmation which is needed if we ever want too see Bitcoin as payment option. I know zero-confirmation is risky, but it should be fine for small transaction and the receiver can re-broadcast the transaction to different nodes to prevent double-spend attempt.
1. Your idea require new proposal and hard-fork.
2. This can be abused to tricking seller, merchants or the receiver in general.
3. AFAIK, your idea could be achieved similarly with scripting, specifically with HLTC.
4. Increasing node loads since the node need to do extra checking.
5. Even if majority accept the idea, i'm sure the adoption will be very slow and another major chain-split will happen.
6. Your idea is killing zero-confirmation which is needed if we ever want too see Bitcoin as payment option. I know zero-confirmation is risky, but it should be fine for small transaction and the receiver can re-broadcast the transaction to different nodes to prevent double-spend attempt.
Copy #2 :
Transaction fees is collected by the miner. This becomes much more important once the mining rewards caps out (in year 2134). From that point on the only source of income for the Miners will be this transaction fees
Original 2 :
Just to add to the discussion ...
Transaction fees is collected by the miner. This becomes much more important once the mining rewards caps out (in year 2134). From that point on the only source of income for the Miners will be this transaction fees
Transaction fees is collected by the miner. This becomes much more important once the mining rewards caps out (in year 2134). From that point on the only source of income for the Miners will be this transaction fees
Copy #3 :
The really important thing to note is the control of the wallet. If the wallet has any funds in it and the wallet passphrase is known or not set, anyone who has access to the RPC interface can send commands to the wallet that result in the coins being sent elsewhere. Thus an attacker could potentially steal your coins if the RPC interface is insecure.
Original #3 :
bitcoind's JSON-RPC interface is used to issue commands to bitcoind to have it do things. Having access to the JSON-RPC interface of a node means that you have a significant amount of control over that node. For example, an attacker can dictate what nodes that node connects to, send coins from the wallet, shut down the node, etc.
The really important thing to note is the control of the wallet. If the wallet has any funds in it and the wallet passphrase is known or not set, anyone who has access to the RPC interface can send commands to the wallet that result in the coins being sent elsewhere. Thus an attacker could potentially steal your coins if the RPC interface is insecure.
To secure the RPC interface, you set a password on it. This password is most securely set by using the rpcauth configuration option. You can generate a correctly formatted rpcauth line by using the script provided here: https://github.com/bitcoin/bitcoin/tree/master/share/rpcauth. That script can also generate a secure password for you to use.
Additionally, you should add rpcallowip= lines to your config file to limit the IP addresses that are allowed to access the RPC interface of bitcoind.
The really important thing to note is the control of the wallet. If the wallet has any funds in it and the wallet passphrase is known or not set, anyone who has access to the RPC interface can send commands to the wallet that result in the coins being sent elsewhere. Thus an attacker could potentially steal your coins if the RPC interface is insecure.
To secure the RPC interface, you set a password on it. This password is most securely set by using the rpcauth configuration option. You can generate a correctly formatted rpcauth line by using the script provided here: https://github.com/bitcoin/bitcoin/tree/master/share/rpcauth. That script can also generate a secure password for you to use.
Additionally, you should add rpcallowip= lines to your config file to limit the IP addresses that are allowed to access the RPC interface of bitcoind.