Bitcoin Forum
March 29, 2015, 05:20:18 PM *
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 100 101 ... 801 »
1001  Bitcoin / Bitcoin Discussion / Re: PSA: Add a Full Node for just $19/year! on: May 20, 2014, 02:27:40 AM
But ppl that get nothing out of it should really think twice before spending their hard earned money

Most people run a full node because they gain security from having the ability to independently verify txs and blocks.   There is nobody who gets "nothing" from running a full node other than someone who doesn't own any Bitcoins.  Satoshi had already considered that in time most users would not run a full node.  This is covered in the white paper written a year before the genesis block.  The security model doesn't need everyone to run a full node.  If someday 100,00 merchants accepted Bitcoins they would have a vested interest to run full nodes to ensure the network remains decentralized.  Even if only 10% of them do that is more full nodes then currently exist today.
1002  Economy / Economics / Re: IRS says mining is "income" (40% tax) instead of cap. gains (20% tax) on: May 20, 2014, 02:23:06 AM
Yeah none of that has anything to do with a Section 179 Deduction.
1003  Alternate cryptocurrencies / Altcoin Discussion / Re: The Bitcoin scripting system is purposefully not Turing-complete - why? on: May 20, 2014, 01:22:05 AM
this would be a problem for Color Coins and Counterparty and certainly anyone who chose to invest in assets on those networks.
Agreed.

Quote
I predict there will be a tension between those who maintain the core features of Bitcoin(and it's status as the reserve cryptocurrency) and those who are attempting to overlay new features.
Agreed. 

Quote
These new features may seriously threaten the basic functions of Bitcoin.
Disagree.
1004  Bitcoin / Development & Technical Discussion / Re: Length of redeemScript on: May 20, 2014, 01:16:33 AM
Yes that is right (except you have a typo in the P2SH script and IIRC it is reversed on the stack).

Still nobody is going to patch out Pay2Pubkeyhash.  I was just pointing out that because it was added after the fact in order to work with the existing scripting engine it is kinda a kludge.  You have a script in the output which says to use a second script in the input (which is located in the signature of all places) to determine the condition required to redeem the output.   It was done this way in order to shoe horn scripthashes into Bitcoin 2 years after the genesis block without breaking compatibility with existing scripting.  

Still if you were going to build a scripting engine with no legacy support I think you can see it wouldn't be built that way.   If starting from a blank page, the output could contain the ScriptHash.  I don't mean a ScriptHash buried in a script but just the ScriptHash (i.e. ScriptHash vs OP_HASH160 <ScriptHash> OP_EQUALVERIFY).  Then all inputs would have a field for the redeemScript and there would be a seperate signature.  All transactions would have the same format for inputs and outputs.  If nothing else it would make figuring the damn thing out a lot easier. Smiley
1005  Alternate cryptocurrencies / Altcoin Discussion / Re: The Bitcoin scripting system is purposefully not Turing-complete - why? on: May 20, 2014, 01:01:14 AM
the payoff of an attack becomes exponentially higher.  The chain could be carrying trillions of dollars in securities and such.  Therefore the payoff of reversing transactions are similarly increased.  This creates greater incentives, and in this age where hashing power is brokered and transferred to different hands instantly- an attack starts to appear more immanent.

If NXT provides better security for assets then assets will be transacted on that network.   So what is the problem again?
1006  Alternate cryptocurrencies / Altcoin Discussion / Re: The Bitcoin scripting system is purposefully not Turing-complete - why? on: May 20, 2014, 12:53:44 AM
to further back up my point, here are some trading stats from the NYSE.

http://www.allcountries.org/uscensus/835_volume_of_trading_on_new_york.html

so in 1999, we had daily highs of several billion trades a day.  Since 2000 this has increased considerably.

now keep in mind that under the current schedule for ie. Color Coins, *creating* a new ticker costs a few cents.  Thus it's reasonable to expect even more than 1 billion transactions a day.  I think you're ignoring the problem because you would rather attention not be going to alternatives like NXT that do have the possibility of supporting this sort of volume ...

I am not ignoring the "problem".  Volume on NYSE is in the billions of shares because fees are insanely low, less than $0.00004 USD net (88 satoshis) per share traded.   Any assets traded on the blockchain would need to compete with bitcoin transactions and fees will probably be at least a magnitude higher.   If NXT is more economical for colored coins then the assets will move there so I don't see a problem either way. 

There is no such thing as "too many transactions" what types of transactions are viable will change over time depends on the cost and limits imposed by the network.  For example the US fedwire (bank wire) network processed 134,244,177 transactions last year.  That works out to about 4 tps.

1007  Alternate cryptocurrencies / Altcoin Discussion / Re: The Bitcoin scripting system is purposefully not Turing-complete - why? on: May 20, 2014, 12:23:52 AM
surely there must be SOME limit there.

Yes but it is self resolving.  Someday a large number of merchants combined may produce 10x as many txs the dice site.  Does that mean Bitcoin is doomed.   It is inevitable it will get so popular it will produce "too many transactions" and then die?   Of course not.  As tx volume rises, tx will compete for space in the next block and fees will discourage low value transactions (like martingaling 100 sat starts to look stupid when it will cost you 10x in fees).

Quote
These other 'rider' networks like Color Coins don't necessarily have any relationship to the price of BTC at all and that's going to be the basic problem from which many technological issues will emerge.

They still have to pay fees like any other tx.  If tx volumes rise sufficiently those colored coins concepts may find themselves stuck on a network where moving their assets is prohibitively expensive.   
1008  Alternate cryptocurrencies / Altcoin Discussion / Re: The Bitcoin scripting system is purposefully not Turing-complete - why? on: May 20, 2014, 12:20:10 AM
but i think my point about some (eg dice-like) contracts would create many more transactions still stands. afaik there is no coin which could handle a large  tx volume (though 100 bets/sec might be possible in the future).

Not true that implies Bitcoin will eventually become so popular it fails.  Eventually 1000 merchants or 10,000 merchants or 100,000 merchants would generate the same tx volume.   Fees will keep tx usage in line.   A 1 bit fee is cheap if you are transferring 1,000,000 bits but you might think twice if you are trying to transfer 2 bits.   Still fees can't resolve the problem of UXTO bloat and that was a problem.
1009  Alternate cryptocurrencies / Altcoin Discussion / Re: The Bitcoin scripting system is purposefully not Turing-complete - why? on: May 20, 2014, 12:10:57 AM
Actually I don't. What happened?

(And if whatever it was doing was done on bitcoin, you didn't answer my original question about ethereum)

too much transaction which bloated the chain.
as many try martingale wth dice sites i think this would happen with this contract.

Well there is no such thing as too many transactions.  The problem was that the site used a "payment" of a single satoshi as notification that a player lost.  This bloats the UXTO which is a more critical resources.  Spent tx can be pruned but to validate future txs and blocks nodes need to maintain a copy of the UXTO.  Normally most outputs in the UXTO are eventually spent (and create new outputs) so the UXTO grows much slower than the overall blockchain.  The problem with single satoshi outputs is they are never economical to spend so they probably will never spend.  This means the UXTO starts growing on the same order as the overall blockchain.

Site like this are one reason the dust rules were created.  They discourage creating outputs that will probably never be spent to prevent them from remaining in the UXTO forever.
1010  Alternate cryptocurrencies / Altcoin Discussion / Re: Decentralized Timestamp on: May 19, 2014, 09:51:40 PM
The way Nxt does it is actually quite clever and solves the nothing at stake problem, there is more to it than this but the part of it that I understand is that choosing who forges next is every forger does SHA(last forger public key) Somehow how long ago an account forged and how many nxt owned by that account and information from the last block is factored in as well.  The winner is the one who has the largest hash.

Saying you know something is solved because of "somehow" kinda implies you don't know it is solved right? Smiley

The network can't require a specific account solve a given block as if it did then it would be easy to halt the chain by just not solving a block when it is your turn.  The network instead favors one block over another one at a given height.  However what happens when both chains have blocks that are worse than the block on the other chain at a given height.  Ultimately the attacker (which had 51% of the stake at the point of the split) will build the best chain overall despite each chain having better or worse blocks at any given height.  

Does the secret sauce in NXT prevent a 51% attack by a stakeholder who had a majority of the stake but no longer has it?  Maybe.  Saying "somehow" or "secret stuff" makes it stronger is hardly compelling though. No explanation of what is publicly available provides a credible reason why the network can't be attacked.  If it really does solve it then eventually it will be publicly available and clear to everyone right?
1011  Alternate cryptocurrencies / Altcoin Discussion / Re: Decentralized Timestamp on: May 19, 2014, 09:35:30 PM
How does Bitcoin solve people downloading the wrong chains?  You could simulate the Bitcoin blockchain from genesis block with less forging power, the difficulty would therefore be lower and people would download the wrong one, right?  Surely the current miner doesn't pass back all the info needed to build a chain from the genesis block every time he solves a hash, right?

You can trick a node into download a chain with less difficulty, but you can't trick the node into using it.  The former is a potential resource wasting attack, the later is required to defraud nodes.

This attack is most disruptive against bootstrapping nodes (because the difficulty was low for a very long time) which is why many clients use checkpoints to limit the disruption a node can accomplish.  It is important to understand that even without checkpoints a peer will still be able to determine the chain with the longest difficulty it just may take additional resources.  Bitcoin nodes may be a little too trusting and they can be hardened against "disrputors" but I doubt it will ever become a useful attack.  Even if a node is naive an entire chain of headers it is only 8MB per 100,000 blocks (two years of blockchain history) even modestly "smart" nodes can limit the scope significantly and thus put an upper bound on the resources a disruptive node can waste.
1012  Bitcoin / Bitcoin Discussion / Re: BitPay raising $30 million of capital, gives itself a ridiculous valuation on: May 19, 2014, 09:09:56 PM
Guess what, Richard Branson and Peter Thiel have done valuations before.

/thread.

It is worth whatever someone is willing to pay for it and people were willing to pay it.  Now Branson and Thiel may have massively overpaid as concluded by armchair investors who have never written a million dollar check before but I doubt it.
1013  Bitcoin / Development & Technical Discussion / Re: Length of redeemScript on: May 19, 2014, 08:37:19 PM
Quote
When you're talking about a 'redeemscript' you need to be specific as to which transaction you're talking about it in.

redeemScript is a proper name.  It has a single specific meaning.  Scripts are limited to 520 bytes.  redeemScript is always in the input of a transaction which is referencing a P2SH output of a prior transaction.

Quote
Let's say you have a transaction B, which is using as its inputs the outputs from transaction A.
In transaction A, the 'redeemscript' would be a fixed-length hash.  (8 bytes?  16? I'd have to go look)

That is close but not correct.  This gets a little in the weed so someone just wanting to know what redeemScript is see above.

Outputs define the terms which encumber how the output can be used, this is (poorly) named the scriptPubKey.  The scriptPubKey does (normally) contain a hash but it will either be a scriptHash or PubKeyHash.  Both are 32 bytes (SHA256 is 256 bits) but they are not the redeemScript.

scriptPubKey ("output script")
Pay2PubKeyHash Tx: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Pay2ScriptHash Tx: OP_HASH160 <scriptHash> OP_EQUAL

When technical docs refer to the redeemScript, it is referring to the script in the ScriptSig (yet another poorly named element) of the input of a transactions.  There is only a redeemScript when redeeming a P2SH.

scriptSig ("input script")
Pay2PubKeyHash: <sig> <pubKey>
Pay2ScriptHash: <sig-0> ... <sig-n> <redeemScript>

For an input to be valid it must meet the conditions which encumber ("lock") the output.  For P2SH transactions the terms are defined but unknown as a P2SH output only contains a ScriptHash.   So the redeemScript is appended to the signatures in the ScriptSig.  In validation the redeemScript is hashed to verify it matches the ScriptHash in the prior output.  The input is then verified to ensure the signatures meet the requirements of the script.  

There is no redeemScript in an input which references a Pay2PubKeyHash output.  The output contains the actual script not a hash of the script.  It is also possible to create other non-standard transactions which define the conditions in the actual output however those are deprecated in favor of P2SH outputs.  Anything you can do directly in the output can be done in a redeemscript and the ScriptHash placed in the output.  P2SH provides a better way to handle "where to put the conditions".  Still the use of P2SH for almost everything except Pay2PubKeyHash kinda sticks out as this weird special exception.  There is no reason it couldn't just work like any other P2SH script (i.e. address becomes not the encoded PubKeyHash but the encoded ScriptHash) then all inputs are P2SH inputs.  If you wonder why we have two different ways of doing the same thing see the semi-OT side note below.


side note (just some pointless D&T pontificating):
If it seems like Pay2PubKeyHash is treated as a "special case" well it is.  More generally the script can either be in the output or a hash of the script in the output (and then a copy of the script added to the input).  All transactions from the most complex to the simplest could be done either way but there is no reason to have two redundant methods to accomplish the same task.  The reason this exists is because P2SH didn't exist in the original Bitcoin.  Outputs (even for "sending coins to an address") are always scripts.  It works for simple scripts but more complex scripts become clunky as the sender needs to know the entire script not just which key to use.  Providing the sender with a hash of the script is superior for a lot of reasons.  It is a good separation of concerns.  So Bitcoin was forked to support P2SH.  Technically support for Pay2PubKeyHash outputs could have been removed (you can generate a P2SH address for a single key script) but it wasn't.  Support for having the output contain the script remained (primarily to support "normal" Pay2PubKeyHash transactions).  It is very likely that P2SH will eventually replace all other transactions leaving only Pay2PubKeyHash which defines the script in the output making it a special exception in practice if not protocol.

If Satoshi had thought of P2SH from the beginning it could have eliminated the redundancy of having scripts in both input and output.  P2SH is normally used for complex scripts but there is no reason a very simple script like OP_CHECKSIG <PubKey> can't be used.  Instead of providing the sender an address which decodes to the PubKeyHash (and then the client knows to stick it into a special output script) you would provide the sender an address that decodes the the hash of this simple script.  You can use it right now for your existing keys - it will produce a different address for the same key though*.  If an altcoin supported this from day zero then the output could be simplified further.  There would be no need for any opcodes in the output.  They would just contain the script hash.  This would not only make transactions smaller it would more importantly reduce the size of the UXTO.

* Warning: Any time you work with custom scripts always use testnet.  You can permanently lose funds due to invalid or misformatted scripts.
1014  Bitcoin / Bitcoin Discussion / Re: Total number of bitcoins will DECREASE on: May 19, 2014, 07:19:50 PM
If 1% of coins are lost each year how many years before all the coins are lost?

Linear loss rates don't make sense.  That would imply people are as careless with a 10KG gold bar as they are with a US penny.  As value rises people will become more careful with their holdings.  At one time 2,000 BTC was worth $1.  Pretty easy to see how someone might be careless with thousands of BTC possibly leaving them in an unencrypted wallet on an unraided drive with no backup.  If you had 2,000 BTC today would you be as careless?
1015  Bitcoin / Bitcoin Discussion / Re: Multiple BTC wallets for security? on: May 19, 2014, 06:57:56 PM
From a practical perspective, I don't see how a paper wallet provides any more security than a wallet on your computer.  In order to move the coins from your paper wallet, you have to import the private key to your online computer and if your computer is compromised, you lose control of the coins just like the wallet was on your computer all along.

Paper wallet is a means of storage it isn't incompatible with using an offline client for signing.  Someone however could buy $1,000 worth of BTC and in a fairly easy, fast. and straightfoward manner secure them offline via a paper wallet.  If they are a buy and hold kind of investor that may be all they need for ... now.   If Bitcoin goes nowhere well it didn't take much to get started but say Bitcoin over 5 years does explode and there $1,000 in now worth a couple hundred thousand.  Pretty easy to buy a netbook or some other device to act as an offline signing device and import the private key directly on to that device.
1016  Other / Beginners & Help / Re: Better way to do paper wallets? on: May 19, 2014, 06:42:21 PM
I'm not as tech savy as you guys. I'm probably just gonna take my printer out back when I'm done with it and shoot it.

Bitcoin approved printer disposal method:
http://youtu.be/WsBB93IqJkE
1017  Bitcoin / Mining speculation / Re: Around which year will the production per block will get halved? on: May 19, 2014, 06:39:51 PM
Reward-Drop ETA: 2016-08-18 21:30:50 UTC (117 weeks, 3 days, 7 hours)

I think this is about as accurate as we can be, this far out.

That assumes 0% hashrate growth between now and block 420,000.  That is probably the least likely scenario.  The date will depend on what is the average time between blocks which will depend on the average hashrate growth between now and the halving.   A hashrate growth of 10% to 20% seems more likely than 0%.  That moves the range to March to June 2016.
1018  Bitcoin / Bitcoin Discussion / Re: PSA: Add a Full Node for just $19/year! on: May 19, 2014, 06:22:34 PM
Since introduction of ASIC's, bitcoin does not deserve private full nodes aside from those that miners use. Those who make money out of it, should pay for it too. If Bitcoin community and developers wanted spread out, uncentralized, node distribution, they woul never let ASIC's inside Bitcoin. One single little change in code would diaable all known ASICS. After that change no one else would ever try to create another one as they would know that their investment would fail as protocol would change again (noone would invest milions into creating chips that would be rendered useless as soon as they hit the network).

That is silly.  I run a full node (actually a number of them) because I personally benefit from having a trustless connection to the network.  Running multiple nodes allows our company to ensure we aren't isolated.  That isn't going to change in the future.
1019  Bitcoin / Mining speculation / Re: Around which year will the production per block will get halved? on: May 19, 2014, 04:30:08 PM
The time between halvings isn't measured in days it is measured in blocks; the subsidy is reduced by half every 210,000 blocks.  The next halving will be at block 420,000.  We have 118,426 blocks to go.  If the network hashrate was stable than 144 blocks would be produced each day.  To reach block 420,000 would take 822 days.  The network however is still growing and thus on average more than 144 blocks are produced each day.  As long as the average hashrate between now and the halving increases (which is almost certainly true) then the halving will occur earlier.  How much earlier depends on the average change in hashrate between now and block 420,000.

Growth Per Difficulty Period | Halving Date
0%  | 8/18/2016
10% | 6/04/2016
20% | 4/03/2016
30% | 2/10/2016

My guess is we reach block 420,000 in the summer of 2016.
1020  Economy / Economics / Re: Gavin Andresen: Rising Transaction Fees Could Price Poor Out of Bitcoin on: May 19, 2014, 04:22:29 PM
Block chain transaction volume is no higher than it was 2 years ago. This is a non-problem unless Bitcoin use increases, which doesn't seem to be happening.

I'm surprised it even have tendency to fall. Why is that? Answer is simple, the sea of altcoins...

It hasn't fallen.  On a day to day basis there is a lot of volatility in the number of transactions.  Volume also tends to spike when the price makes major moves (highest volume days tend to be around ATHs and ATLs).  If you look at transaction volume on a moving average it has steadily increased.

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 100 101 ... 801 »
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!