If that happens government paper currencies will become worthless Really. The US dollar is currently the defacto world currency (although how much longer remains to be seen) so that means all other national currencies are worthless? Euro? Pound? Yen? Interesting. |
|
|
|
DPOS and NXT are practically identical, the only difference is which mechanism is used to pick block producers (both are essentially by stake-vote)
In NXT you can also form forging pools and may lead to Bitcoin style problems. The forging pools with nxt equal the delegates in dpos. This is what makes them equal. Not necessarily. The problem in Bitcoin pools is that they are not limited, and the same problem exists with pooled forging. With DPoS, there is a limit to how much votes each can collect, and any delegate can not dominate; at least openly. If GHASH split into 3 pools with the same combined hashing power but owned and operated by the same entity would that make Bitcoin more decentralized? |
|
|
|
|
Strange that development just ended due to "support for XP ending". The explanation ignores the fact that people would want to use TrueCrypt on Linux, OSX, and later versions of Windows. I wonder if a three letter agency coerced the development team into integrating backdoors and rather than do that they just ended development?
|
|
|
|
One more question, is there a luck factor at all ? If I burn 50 coins now, can someone who burnt only 1 get the PoB reward ? Yes they could, except relative to the guy that burned 50 coins, the person that burned 1 coin would have a 50 times smaller chance of finding a block. Once a pool is made, both will get coins but the 50 coins guy would get 50 times the reward the 1 coin guy will get. Wow. Such broken concept. If I have 50 TH/s and you have 1 TH/s I will on average get 50x the reward. Is that also a broken concept? |
|
|
|
Does the Bitcoin Core still broadcast double spends that come in later? The Bitcoin Core client has never broadcast, relayed, or included double spends in a block. |
|
|
|
A penalty for an inactive but otherwise non malicious forgers is useful but it doesn't help in a 51% attack. By definition in a 51% attack the attacker IS NOT mining the main chain so a penalty that doesn't allow him to mine on the chain he already isn't mining isn't much of a penalty is it? On the other hand in the attack chain it will be the legit miners who failed to mint a block and they will be subject to the penalty. When the attack chain is longer and the attacker broadcasts it, then it becomes the longest chain and some or all of legit miners will be penalized for up to 1440 blocks. |
|
|
|
|
Yes. The exact details will vary by application but at a high level the data layer contains the application details (user "balances", deposit addresses, tx history) and bitcoind is merely used as a conduit to connect the application to the bitcoin network.
|
|
|
|
I wanted to create a website where when a user signs up they are given a bitcoin wallet where they can send bitcoins to and from. Does anyone what do sites like nitrogensports.eu and cloudbet.com use?
I read through the blockchain wallet api. Are there any alternatives to that?
This question is probably hard to understand and I may not have used the right words to describe my question. Sorry
The easiest way to do this is bitcoind. You don't even need a database. Just getnewaddress(account) and it will give the address with the account name you put. You can even have an account name that ends with a password hash if you want to have a login system on the site. Then move() to the new address from the main wallet account that is an address with an empty account name string. Now the user has a balance and he can fill it by sending coins to his address. Then if the user withdraws, use sendtoaddress()+move again (and incluode failsafe so he's not allowed to withdraw himself into a negative account balance. Don't use bitcoind accounts. They don't scale and once you build a system around it you will be trapped in a technological dead end. Use bitcoind as a processing engine and handle your user data in the database. |
|
|
|
For a solution for this to work for everyone with or without hdd space. Blockchain should be on the cloud and a small index file downloaded to ones system and then qt wallet for computer or mobile phone or tablet can easily be updated and a small amount of data to be put on system. This would not only free up space on peoples computers but it would also allow faster transactions to go though the network. A lot can be done to improve services and I disagree for new users to be penalised because their new to the services. What happens if 1 million new business want to start accepting it for their business and they have to wait ages to download the blockchain and update their wallets. It wouldn't work out it would deter more people from using it.
No the solution is to use a SPV client. The network is already the "cloud". Satoshi solved this problem a year before the genesis block was minted and people keep trying to come up with inferior "solutions". If you want to be a full node there is no substitute for the (pruned) blockchain. You don't need to be a full node, you can operate as an SPV client instead. There is no reason to try and combine the both into a solution which takes the worst elements of each and accomplishes nothing. |
|
|
|
if PoS provides for more security how come advanced check-pointing was conceived with PoS only?
Because it isn't. PoS suffers from a "nothing at risk" problem. An attacker can use coins they no longer have but did have at one point in the past to attack the network. Actually there is no reason to not do this. If the attacker is unsucessful well they lose nothing in the attempt and if they are successful they get all their coins "back" (that they may have lost, had stolen, or sold). Checkpoints limit how far back the chain can be reorged but they don't solve the nothing at stake problem, only limit the extent of the damage. Please tell us which PoS coin has been attacked by so called "nothing at risk" problem. None definitively although more than one POS coin has been 51% attacked. Many of them have stake requirements which are negligible so often cheap attack is easier than a more sophisticated nothing at stake attack. No POS coin has extensive history in the field other than PPC and it avoids an attack by using 100% centralized checkpoints. Still you don't really believe that "hasn't happened" = "can't happen"? Bitcoin has never been 51% attacked therefore you believe an attack is impossible? |
|
|
|
There are this many addresses
1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976
What, currently or possible? The number of possible addresses (2^160) Currently there are only 6M addresses associated with any unspent output ("funded"). If you are worried assume there are 1 billion Bitcoin users and they each generate 1 billion new addresses per day. How long would it take to generate 1% of the possible addresses. |
|
|
|
This will require some thinking. Perhaps for m-of-n support, the "claim to" string could be signed by m of n addresses and the string + all the signatures could be wrapped and broadcast to the spin-off network. The nodes would look up the address, read the redeem rules from the snapshot.bin file, and ensure that a sufficient number of correct signatures was present. With P2SH the redeem script is not known to the network until the output is redeemed so the user would need to supply the redeemscript in the claim message. It could then be signed by as many keys as necessary. But are there other common redeem scripts besides the standard single-address script and m-of-n multisig (native and P2SH)? I realize we could implement the full bitcoin transaction verification procedure to handle arbitrary scripts, but I was hoping to avoid this if possible. A P2SH address is just the hash of a script. The script can be anything that the Bitcoin scripting language allows. I would guess most redeem scripts are probably fairly straightforward multisig but the redeemer supplies the redeem script so using just the blockchain there is no way to know what the scripts for the X unspent outputs to P2SH addresses are. It probably would be a good idea to develop an UXTO parser to categorize what portion of the outputs belong to the following defined templates 1) PayToPubKey (obsolete but was used in early coinbase txs) 2) PayToPubKeyHash 4) PayToScriptHash 5) Native Multisig (not P2SH, multiple PubKeys specified directly in the tx output) 6) Non-standard * * Note it is possible that some P2SH scripts are also non-standard but we can't categorize them as we don't know what the script is. For this "template" we mean all outputs which don't conform to any other known template. Somewhat related, you may find that having complete support for the range of possible Bitcoins scripts is rather code intensive. Your claim module/class can be rather heavy and that makes all future clients heavy as well. Having a defined claim limit would allow you to drop that code for some clients in the future. Once the claim limit has passed and the limit is thousands of blocks deep into the blockchain and behind a checkpoint or two most nodes could probably drop support for validating claim txs and just accept that if they are behind the checkpoint and in blocks thousands of blocks deep in the longest chain then they are valid. |
|
|
|
-snip-
This is not necessarily true.
Miners (or mining pools) can choose which transactions they will confirm. Some miners may feel that the orphan cost of increasing the size of their block is more than 0.0001 BTC per kilobyte, and may therefore choose not to confirm transactions unless they pay a slightly higher fee. -snip-
Thanks for the correction. I was aware that pools can choose which transactions they accept. I did not think that any pool would consider the default fee to low though. I guess the threshold would usually not be common knowledge, since there is no mention of it in the usual lists 1. Is there any pool out there that actually considers .0001 per KB to low? [1]: - https://bitcointalk.org/index.php?topic=104664.0- https://en.bitcoin.it/wiki/Comparison_of_mining_poolsI don't know of any major pool which requires a fee higher than 0.1 mBTC per KB. In most scenarios (unless the tx has other issues) a fee of 0.1 mBTC will be sufficient for inclusion in the next block. If the next block is "full" (limit on size set by miner) then it is possible one would need to wait for the following block. Paying 500% of the "min fee" however is almost certainly just a waste of money. The situaiton will become more complicated in the future. v0.90 allows relaying txs with a lower fee of only 0.01 mBTC per KB. To avoid fragmenting the network it doesn't allow creating txs with a fee that low when a fee is required. Once a majority of the network is using v0.90+ a new version of the client will be released that also allows creating tx at that fee level. Will miners accept the 90% reduction in min fee? Will some of them insist of keeping the current fee? Will some adopt a fee between 0.01 mBTC and 0.1 mBTC? It will be interesting. It would be nice if at least all the major pools publicly posted their tx inclusion policies. If you know even the policies of 60% or so of the hashrate you can make pretty good estimates on what fee amount is required based on how quickly you need a first confirmation. |
|
|
|
Also, A/C's have an efficiency of ~30% which means it would take a 4000 watt unit to remove the heat from your 1260 watts worth of gridseed blades. Um AC have an "efficiency" of 300% to 500%+. They are heat pumps. 1W of electricity is sufficient to move 3 to 5W of heat. |
|
|
|
Thanks for the informative reply. So address reuse cannot expose the random number generator scheme of the machine. It is a problem when k is reused but a sequence of k's generated cannot give any info about the random generation algorithm so other private keys generated by the machine are safe.
Also multiple time signing with different k's does not weaken ECDSA right? For example reducing the search space.
If the PRNG on the device is cryptographically strong and has no weaknesses or backdoors then there is no issue with key reuse. From an academic point of view each additional signature does slightly reduce the security of the key but this has no real world practical value. Even with millions of signatures the key would still be not breakable by brute force. However proving a device is using a random k value with high entropy is very difficult. It would be better for the device (if possible) to use a deterministic but still secret k values and deterministic signatures. There is an existing standard RFC 6979. Since the k value and derived signature are deterministic it becomes very easy to audit the device. Load the device with a known private key, have it generate a series of test signed transactions, then compare that to the output of a reference client (also using RFC 6979). Any deviation would be immediately recognizable. |
|
|
|
2. Does anyone have insight into the best format for the section in snapshot.bin that contains funds unlocked by multisig and other complex scriptPubKeys? Keep in mind that multsig can either be in the form of "native" multisig (script is in the output) or P2SH (scripthash is in the output). P2SH is the easier format to handle. It would be recorded in the snapshot identically to PubKeyHash balances. Claiming the credit would require a more complex message as you would need at a minimum the redeemscript as well as the require number of signatures. Maybe I missed it but what is the reason for not just having the spinoff client handle the claim tx? Is it that you want to avoid importing bitcoin private keys into a different client? |
|
|
|
|
One thing to keep in mind is that bitcoin doesn't just sign the message as input by the user. It appends a header to the message and signs the header+message. This is done as a security measure to ensure a user can't be tricked into signing a tx. The claim source code would need to be aware of the format of the bitcoin sign message header.
|
|
|
|
|
Am I missing the obvious? What about BTC or XBT?
|
|
|
|
I would love to have a miner that runs in my car while I am driving, no extra power cost That would be called magic. |
|
|
|
|
Show Posts
