Bitcoin Forum
March 06, 2015, 12:02:57 AM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 [49] 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 ... 798 »
961  Bitcoin / Development & Technical Discussion / Re: Understanding Basic Transaction Structure on: May 18, 2014, 05:10:53 PM
Well there is no address in any transaction so you don't need to decode the address (but you will need to decode the output script).  There is no such thing as a balance, when a wallet says it has an X balance it means the sum of the value of the unspent outputs it has the ability to spend is X.    There are just inputs and outputs.  Inputs reference a prior unspent output so you don't need to add them.  Outputs are either spent or unspent.  If an output is referenced is a future transaction input then it is spent.  Only unspent outputs can be spent in the future so your "balance" is just the sum of the outputs which are not yet referenced in an existing transaction's input.

There isn't necessarily a 1:1 relationship between outputs and public keys as outputs are actually scripts and can be in a variety of formats.  So if you want to handle all possible outputs your parser will need to decode the scripts.

The most common formats are
PayToPubKey (obsolete was used in early generation "coinbase" transactions)
PayToPubKeyHash (what most people think of as a "normal" transaction)
PayToScriptHash (aka P2SH, the address encodes a script hash not a pubkeyhash so payments are locked by the terms of a specific script)
Native Multisig (output script contains multiple public keys and OP_CHECKMULTISIG opcode)

P2SH and native Multisig are both methods to encumber an output with multiple keys.  They do the same thing in different ways.  In native, the output contains the actual script.  In P2SH the output contains the hash of the script needed to "spend" the output. P2SH is more common now and is often just called multisig which can make it complicated.

Here is a transaction with a native multisig (1 of 2) in the output (vout[0]): 60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1
Here is a transaction with a P2SH output (vout[5]): d9a2ef9c07ab71ac12680df72cbbbf6153e7bb7ea511eb8ca764f434d378bbea

Yes Bitcoin is complicated.

We often talk about "sending coins to this address" but that kinda breaks down at the actual protocol level.  All outputs (as in all even "normal" transactions) are scripts.  The script defines what is required to spend that output.  If you use term like "balance of pubkey" in the case of multisig (either native or P2SH) which PubKey "has" the balance of the output?  With native multisig there are multiple pubkeys and a single output.  With P2SH you may not even know the script yet (just a hash of the script) so you have no way to determine which PubKey(s) can spend it.

If you wanted to limit it to "normal" transactions (PayToPubKeyHash) you could just ignore all outputs which don't match this template

This may be a good first step.
962  Bitcoin / Bitcoin Discussion / Re: Do you think this is what bitcoin is? on: May 18, 2014, 04:42:36 PM
Also bitcoin doesn't use encryption, it uses cryptography (hashing algorithms and digital signatures).  There is nothing encrypted in the bitcoin network (although some clients may optionally encrypt wallets when not in use).  Normally I wouldn't care but if you are going to take the time to explain something you should start with the correct terminology.  Your private keys allow you to sign transactions and that is what limits access.
963  Bitcoin / Development & Technical Discussion / Re: what could prevent the sender from preparing a chain of blocks ahead of time? on: May 18, 2014, 03:53:04 PM
What video?

What you described is a double spend.  It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power.  It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely.  The more confirmations the less likely it becomes.

For a deposit of 1,000 BTC the exchange should probably require more than three confirmations.  Meni wrote a very good paper on the economics of double spending.  If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations,  0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations.  The exchange can also protect itself by validating KYC information for users involved in large transactions.

As for your quote.  I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either.  You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim.  I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording.  The paper was written at a theoretical level about a year before the first version of the client was completed.
964  Bitcoin / Development & Technical Discussion / Disincentive to confirm transactions when burning (destroying) transaction fees? on: May 18, 2014, 03:36:39 PM
The economics of orphans as it relates to transactions has become more understood in the last year.  I started thinking about how it would affect a currency like Peercoin (PPC) which doesn't compensate miners with transaction fees and instead burns them.   Will this create an economic disincentive for miners to include transactions in the next block?

Peercoin has a low level of persistent inflation.  PoS will increase the coin supply by 1% annually.  Peercoin is a hybrid coin with both PoW and PoS.  The PoW component contributed to the majority of the inflation in its early history but it will decay to a negligible level over time.  For the purpose of this question the PoW component can be ignored.   PPC offsets this new minting by destroying the transaction fees instead of paying them to miners as with Bitcoin et al.   Monetary inflation will approach at rate of:  m = 1% - (tx fees / money supply).  Unlike some inflation zealots I have no issue with this.  Inflation is capped at 1% and in reality will be lower, it is even possible the coin will be slightly deflationary.   In the long run a monetary system with <1% inflation or <1% deflation is not a material change to a money supply which is static.  Burning the tx fees is an interesting way to provide a counterbalance to the continual minting of new coins.  This structure however creates an economic disincentive to miners in the form of uncompensated orphan costs.  This shouldn't be viewed as judgement on the developers.  Peercoin launched almost two years ago and there was less discussion on the economics of transaction selection at that time.

For those unfamiliar with the term, orphan costs refer to the economic cost of including one more transaction in the next block.  All blockchain based currencies have orphaned blocks.  Orphaned blocks are due to a second competing block being found after a miner has found a block but before the block has propagated the entire network (specifically to all miners).  The larger the latency between when a block is found and when it has finished propagating the higher the probability that a competing block will be found.  Although it isn't the only factor the size of the block contributes to the latency.  All other factors being the same a block which is twice as large, will take twice as long to propagate and thus has twice the chance of being orphaned.   The cost can be expressed as Bitcoins (or uBTC) per kB.  If the orphan cost is higher than the fee paid then the miner has no direct economic incentive to include the transaction.  Including the transaction will in the long run reduce the net revenue paid to the miner.  To date most miners have been forward looking and include transactions even if they do marginally reduce net revenue however a system based on direct economic benefit is stronger than one based on charity or working for the common good.  

There are some optimizations that are possible and with Bitcoin the declining subsidy and rising number of paying transactions will reduce the orphan cost over time.  The burning of fees on the Peercoin network means that all transactions are essentially unpaid from the view of the miner.  Peercoin can use the same optimizations proposed for Bitcoin to reduce the orphan cost but the gross revenue for all transactions will always be zero.  This means that all transactions will have a negative effect on net revenue and there is no economic incentive to include the transaction in the next block.  The maximum net revenue is already available by mining an empty block and including any additional transactions only serves to lower the miners net revenue.  The more transactions the miner includes the less net revenue he receives.  Some miners may work for the common good and there is an indirect mutual benefit by supporting the network, however arrangements which lack a direct benefit can lead to a tragedy of the commons.

Do you see this as an issue for Peercoin or more widely for any system where the fees are burned?  How can the disincentive be reduced or eliminated?  I have a couple ideas (but they all involve hard forks).  I will post them later but I would like to see other viewpoints first.
965  Bitcoin / Bitcoin Discussion / Re: Do you think this is what bitcoin is? on: May 18, 2014, 02:42:52 PM
That is a very verbose explanation but there are actually three "bitcoins".  Bitcoin is a protocol that governs the behavior for a decentralized peer to peer network, it is also the software running on the does of that network which implement that protocol, and it is a virtual currency or the unit of account used in the protocol.
966  Bitcoin / Development & Technical Discussion / Re: Understanding Basic Transaction Structure on: May 18, 2014, 02:39:57 PM
There are two types of multisig.  There is "native" multisig where the script and pubkeyhashes are in the vout however that makes for very large addresses.   P2SH was added later.  With P2SH the output is a hash of the script and that makes the address compact.

With native multisig there would be multiple pubkeyhashes in the output.  With P2SH there is just a single scripthash in the output. 

While bitcoin may show addresses understand that addresses are encoded hashes (either PubKeyHashes or ScriptHashes) and they don't exist in the protocol itself.  When you provide an address to a client it decodes the address to the reslting hashtype and the Hash is what is actually placed in the output of the transaction.
967  Alternate cryptocurrencies / Altcoin Discussion / Re: The Bitcoin scripting system is purposefully not Turing-complete - why? on: May 18, 2014, 09:32:00 AM
I believe Ethereum is backing off from that claim and it will not be Turing complete.   Generally the higher the complexity of the environment the higher the chance of undetected flaws, bugs, and exploits.   The idea that one would want a complex Turing complete (or quasi turing complete) scripting language, combined with the overhead of a decentralized network, to process the transfer of money seems a very dubious proposition.   I want my financial processing engine to be as lightweight and simple as possible.  Higher level functionality can be built on top of the network.
968  Alternate cryptocurrencies / Altcoin Discussion / Re: The Bitcoin scripting system is purposefully not Turing-complete - why? on: May 18, 2014, 09:00:43 AM
Can somebody explain to me why the Bitcoin scripting system is purposefully not Turing-complete? To make malicious programs difficult to develop (I guess)? Or because it was difficult to make it Turing-complete?

Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops. (

Attack prevention.  With loops and recursion it becomes more difficult to limit the resources required by a script.  It would be possible to create scripts which crash nodes, scripts which take hours to validate, scripts which consume the host memory.   Any looped code can be unrolled.  The execution time of unrolled code is easy to control by limiting the length of the script.
969  Economy / Economics / Re: IRS says mining is "income" (40% tax) instead of cap. gains (20% tax) on: May 18, 2014, 08:40:20 AM
OK... so none of the Bitcoin miners in the US will be paying any taxes to the IRS. I don't think that Bitcoin mining is profitable anywhere in the world. So the net income is in negative.

I am pretty sure many miners are profitable but for those who produce a loss there is no income tax and the net loss will reduce the overall income reducing overall taxes.
970  Economy / Economics / Re: Gavin Andresen: Rising Transaction Fees Could Price Poor Out of Bitcoin on: May 18, 2014, 08:35:53 AM
People who collect very small amounts of Bitcoin, mostly from faucets are disproportionately affected by the rise in the transaction fees. I have seen people paying as much as BTC0.05 in transaction fees, for transferring just BTC0.1. Their transaction size (in KB) is quite large, therefore they will have to pay a higher transaction fee.  

Imagine how much worse it was if the dust limit hadn't been put in place.  Prior to the dust limit most "free coins" sites were paying out even smaller values sometimes as little as 100 sat.   

It is always better to opt for larger payments if possible.  In pool mining, to reduce fees paid, you should set the payout threshold as high as possible but no higher than an amount you would be willing to lose if the pool fails or defrauds you.   So if you are willing to risk a max loss of 0.05 BTC then payout in 0.05 BTC increments because a single 0.05 BTC output will require less fees to spend than fifty 0.001 BTC outputs.
971  Economy / Economics / Re: If transaction per second increased dramaticaly does it solve miner crisis? on: May 18, 2014, 07:14:26 AM

True, Doge will be the interresting thing to watch fairly soon. Payout wise they will the in a situation that BTC will be in in several decades. Basicly all options are plausible, from total failure and price dropping close to zero to becoming the dominant cryptocurrency.

That isn't plausible and it is reckless to pretend it is.   When it only cost $50 or so to reverse a block the network will have no security.  It will either fail or have yet another hard fork to fix the never ending list of mistakes the developer made.   That is what happens when people take the bitcoin source code and start randomly changing parameters without seeing the implications.
972  Economy / Economics / Re: If transaction per second increased dramaticaly does it solve miner crisis? on: May 18, 2014, 07:10:23 AM
There is no crisis.  Satoshi designed the system well and with four years between halvings it gives the network decades to build up the necessary transaction and fee volume.
973  Other / Beginners & Help / Re: Cold Storage + Fork = ??? on: May 18, 2014, 04:12:36 AM
It is actually somewhat of a challenge to spend pre fork coins on one fork only.  A fork is caused by some of the network using an alternate chain (of blocks).  Transaction which are not yet in a block would be relayed by nodes on each fork unless the tx is invalid on that fork.

One way to make a tx invalid on one fork is to include newly minted coins which can only exist on one side of the fork (because the other side has a different block and thus different coins).
974  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Coin2.0 [C2.0] - The forward thinking POS (FPS GAME DEV. UNDER WAY). on: May 17, 2014, 11:08:18 PM
If c2 is using the peercoin PoW/PoS hybrid, you are right and I am wrong.

Looking at diffs of the two source codes it is pretty clear that c2 is a shallow copy of peercoin.
975  Economy / Economics / Re: Gavin Andresen: Rising Transaction Fees Could Price Poor Out of Bitcoin on: May 17, 2014, 10:51:06 PM
[quote author=curlyginger link=topic=612652.msg6781840#msg6781840 date=1400336909]
One of 2 things will happen long-term, either:
1) The blockchain and miners evolve to more easily support many high volume micro-transactions. The effect will be the cost to miners of managing micro-transaction will be lowered, and this will be passed on in the form of lower fees.

It depends on what you mean by micro transactions.  Transactions of less than 1 US cent (circa 2014)?  Probably not going to happen.  This isn't just a miner issue.   The blockchain is a public record.  The cost of a transaction is borne by all nodes while the cost by be relatively low on a per tx basis it isn't zero.   The other thing to consider is the critical resource is space so tx are always going to be priced on a per tx (well per kb but the tx size for most txs is a relatively small range) not as a % basis.  This means the effective cost of smaller tx as a % of the value transferred is going to be higher.

 That being said Bitcoin doesn't need to have to support txs which are a thousandth of a US penny and have fees of less that are a billionth of a penny.  It just needs to be cheaper, faster, and more secure than the alternatives.   The most successful digital currency in Africa is mPesa which enforces a min tx value of $0.10 and at that level fees are $0.03 per tx (30% of value).  Can Bitcoin beat that?  Yes.

mPesa fee tariffs (values converted to USD)
Min Transfer:   $0.10  fee $0.03 (30%)
Max Transfer: $700.00  fee $1.10 (1.6%)

Min Agent Withdraw:   $0.50 fee $0.10 (20%)
Max Agent Withdraw: $700.00 fee $3.30 (4.7%)

Min ATM Withdraw:   $2.00   fee $0.33 (17%)
Max ATM Withdraw: $200.00   fee $1.93 (1.0%)

Bitcoin already beats mPesa on tx fees.  However mPesa has a superior on the ground network when it comes to "cashing in and out".  With fees as low as 1% when withdrawing from an ATM exchangers would really need to cut fees to be competitive.

So it really comes down to what you mean by micropayments?  Do poor users really benefit from the ability to transaction in subcent values?  Even in Kenya with median income being about $800 annually a centralized network without the cost of blockchain imposed a min tx amount of $0.10 (and with a staggering 30% fee) and it became the most successful virtual currency outside of Bitcoin.[/code]
976  Bitcoin / Project Development / Re: [ANN] Bither - Say goodbye to Hardware Wallets. on: May 17, 2014, 10:43:35 PM
Basic problem is that a phone can die from one second to the next. I had it. Woke up with phone alarm. Went to bus station and wanted to look what time it is. No reaction at all. Mainboard died and i had to wait 2 weeks to get the phone with text: we where not able to restore the data. It was a Note 2 from Samsung. So i would never trust a phone! I had some bitcoins in my phonewallet but i had a complete backup of everything. So no loss.

All electronics can die without warning.   You should always have backup/seed for any device.
977  Economy / Gambling / Re: Does martingale really works? on: May 17, 2014, 10:23:10 PM
As everyone else has mentioned, Martingale doesn't work infinitely. Stop as soon as you get a small amount ahead.

There is no guarantee you will get a "small amount" ahead.  There is no guarantee you will ever be ahead at all. 
978  Bitcoin / Development & Technical Discussion / Re: Question about base58 encoding on: May 17, 2014, 10:06:16 PM
It's the way it's done, but whether it was the most reasonable way to do it, I'd have argued about it. Smiley

Exactly.  It is another "Satoshism".  It makes things more complex for no obvious benefit/reason.  Each one by itself isn't that hard to workthrough but collectively they add up to reduce the transparency of the code.

This does mean that some Bitcoin addresses are shorter however each digit shorter is progressively less likely.  Most (99.7%) addresses are 34 or 35 digits long.   I can't see that being a good reason for all the complexity.  It actually makes it slightly more confusing because you can't say "All Bitcoin addresses are X digits long", you can't even say 34 or 35 digits because in theory they can be as short as 20 digits (version 0x0 + payload/hash of all zeroes + checksum).   No idea why Satoshi didn't just do something like prepend the version byte (where valid version byte is any value other than 0x00) and then convert to base58.  No need for any weird leading 0x00 = "1" check.  By using a version byte of 0x01 or greater the leading zeroes of the hash would be preserved.

It isn't ever going to change now but it does make you scratch your head and it makes it harder to understand the code because there is no obvious benefit (which helps when trying to figure out what a chunk of code is doing).
979  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Coin2.0 [C2.0] - The forward thinking POS (FPS GAME DEV. UNDER WAY). on: May 17, 2014, 09:19:20 PM
so we would expect our attacker to be able to create a blockchain capable of double spending bter aproximetly 1 in every 10 billion instences of a 100 block long chain being created.

I believe your math is incorrect there is no probability of failure (the attack chain isn't published until it is longer and the next block solved by the attacker will always extend his chain).  It is only a question (based on variance) of how many blocks it will take before the attacker is ahead.  

Still that is the minor point so I will accept your assumption.  I don't think you realize how trivial it would be to make 10 billion attempts.  6 digit vanity addresses take an average of 38 billion attempts each and they exist.  10 billion sounds like a large number until you consider the rate at which modern hardware can compute hashes.

tl;dr, yes, but mostly hell no, more confirms make a HUGE difference, mintpal fucked up.

That is a fundamental error in thinking.  An increased number of confirmations improves security under the scenario where the attacker has less than a majority of the hashrate/stake.  If the attacker has a majority of the hashrate/stake then it is a certainty he can produce a longer chain.  No amount of confirmations can provide you with a level of assurance.   I don't really care if you disagree but I would hate for some noob to believe you and then wonder how an attacker did the "impossible" and performed a 100 block or even 1,000 block reorg because he had a majority of the stake.
980  Alternate cryptocurrencies / Altcoin Discussion / Re: Proof of stake instead of proof of work on: May 17, 2014, 08:54:30 PM
From an abstract point of view, it makes no difference if the block height is 0 or if it is X when currently being at X+T and T is huge.

Of course it does.  The hash of block 0 will never change.  I can print it out, put it in my safe and verify that network starts from the same genesis block a century from now.  The hash of X will change periodically and may not be consistent among all nodes.  For NXT it changes twice a day.   If you can't see the difference in the level of verification of a single universal static value which is hardcoded into the client (and if the client is insecure/flawed/noncompliant you have already broken a basic security assumption of all cryptocurrencies) and a locally computed value which is continually changing and may not be consistent for all nodes then well then you just don't want to see.

One could use client using 0 as a checkpoint (for whatever reason) and be on a fork.

The "for whatever reason" makes it a true but pointless statement.  If your node is secure and compliant then you verify the best chain independently UNLESS the protocol has local checkpoints as that behavior is non deterministic.  With a network which needs local checkpoints, you can never independently verify that you are on the best chain. That is a huge problem for a network which is designed for facilitate commerce without a trusted third party.

So to replace it with a meaningful distinction:
Given a secure and compliant node, and a protocol that uses does not local checkpoint rules, then your node can independently verify the best chain.
Given a secure and compliant node, and a protocol that uses does local checkpoint rules, then your node can not independently verify the best chain.

That will be my last post because honestly at this point if you don't see it, then it simply means you don't want to see it.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 [49] 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 ... 798 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!