Bitcoin Forum
June 18, 2018, 12:31:29 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [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 ... 801 »
701  Bitcoin / Bitcoin Discussion / Re: 51% can be prevented so long as all nodes agree. on: June 18, 2014, 12:23:02 AM
Why not change to just one giant pool, sort of. In a pool, the coinbase transaction has the pool's address, not the miner's address. That could be changed to output to a collective list of all miners addresses.

Congratulations, you re-invented P2Pool. Eligius does the same thing: paying the miners directly instead of paying everything to the Pool's wallet (Both examples still use the traditional approach for alt-coins).

There is a bit of a definition issue though: miners generate blocks, while hashers generate proof-of-work. We are in this crisis mainly because those two functions have been separated.

While I understand setting up merged mining may be costly and a lot of work; hashers need to understand that they have to monitor the entities they are lending their hash-power to.

LOL  Except mine would be forced on you.

How?  A pool could connect to p2pool (or your p2pool re-invention) and miners could choose to connect to that pool instead.  PoW is by design a nearly perfectly parallel problem.

One thousand miners can appear to be a single node in any system you devise.  There are some systems proposed but they involve zero knowledge proofs which prevent the (secure) sharing of mining information
702  Bitcoin / Bitcoin Discussion / Re: Bitcoin Addresses: What happens after 20 years? on: June 18, 2014, 12:10:15 AM
No. It isn't.

with no time reference, you can't create a random formula ...

i build microprocessor for industrial use (without NTP chip) ... and random is only possible because crytal frequency is not "regulary the same in identical chip".

the adress of bitcoin must be generate in random and "row" strategy. only based time/date strategy do this.

Yeah that is still wrong no matter how many times you repeat it.   There are plenty of entropy sources which don't involve time.  

that why, in log of bitcoin-qt, you can see NTP mark regulary to correct the main process of mining/RPC orders.

If you are referring to entries like this:

2014-06-13 15:37:50 receive version message: /Satoshi:0.8.6/: version 70001, blocks=305596, us=<nope>, them=, peer=
2014-06-13 15:37:50 Added time data, samples 4, offset +24 (+0 minutes)
2014-06-13 15:37:50 receive version message: /Satoshi:0.8.6/: version 70001, blocks=305596, us=<nope>, them=, peer=
2014-06-13 15:37:50 Added time data, samples 5, offset +25 (+0 minutes)
2014-06-13 15:37:50 nTimeOffset = +24  (+0 minutes)

They are not references to NTP.  It is comparisons of the local machine clock against the network median time.  It isn't used to seed the PRNG but to limit how far miners can drift the timestamps of blocks.
703  Economy / Currency exchange / Re: Buying Bitcoins Wire Transfer on: June 17, 2014, 11:21:53 PM
Forgot you were in Cali. They encountered enough regulatory uncertainty out there that their legal counsel advised not serving that state. Talk to your state Representative and let them know they need to fix that problem.

Should have good news to report regarding this by the end of the week.
704  Alternate cryptocurrencies / Altcoin Discussion / Re: Spin-offs: bootstrap an altcoin with a btc-blockchain-based initial distribution on: June 17, 2014, 11:00:06 PM
It is somewhat surprising.  I would have imagined that the cold storage of major exchanges would be secured by m of n  P2SH scripts.  We know that none of them do that simply because the total value encumbered by all ScriptHashes & Raw scripts is <0.16% of all BTC.

Haven't had much free time to do more analysis of the blockchain but found an interesting test case in this tx:

This tx has (or had as of the snapshot block) 3073 unspent outputs.  It is the largest tx when measured by the number of unspent outputs.
705  Other / Beginners & Help / Re: Lost Half of Private Key - Are Bitcoins Safe? on: June 17, 2014, 09:59:58 PM
It makes it 340282366920938463463374607431768211456 times easier to brute force.

So if you could guess 10^9 per second it'd only take you 10^24 years instead of 10^63 years.

256 bit ECDSA keys only have 128 bit security.  Half of an ECDSA key would be 64 bit security.  While a naive attack would be to increment all possible private keys there are more sophisticated attacks ( ) which are of complexity O( n^(1/2) ) steps where n is the key length.

64 bit security would be breakable but it is very likely the cost to break they key would be greater than the reward.  Although if this isn't a hypothetical I would recommend transferring the coins now.
706  Bitcoin / Development & Technical Discussion / Re: How to sign a text message? on: June 17, 2014, 03:58:43 AM
Yes but I am looking for a function that can sign a text message, instead of a hash...

There IS no such function.  The max length of the digest that can be signed is <256 bits (<32 ASCII characters).  This is a limitation of how ECDSA works.  As there is almost no use for signing a message directly with that limitation a hash is used instead.  So even in cases where the message IS less than 256 bits it is still customary to take a hash of the message and sign that rather than deal with this extreme edge case differently than all other messages >256 bits.  

It sounds like you are trying to use the wrong tool for the job.   The purpose of a digital SIGNATURE algorithm is to digitally SIGN not ENCRYPT messages.
707  Bitcoin / Development & Technical Discussion / Re: How to sign a text message? on: June 17, 2014, 03:56:37 AM
The purpose of signing is not to hide the message it is to authenticate the message.  It sounds like you wish to have the message encrypted not signed.

There are encryption algorithms which work using ECC keys and curves but none of them are used by bitcoin.  The bitcoin protocol uses no encryption at all (although some client side encryption is used to protect private keys). 

Here is an example of a ECC based encryption protocol:
708  Bitcoin / Development & Technical Discussion / Re: How to sign a text message? on: June 17, 2014, 02:56:12 AM
No.  public key cryptography is particularly expensive so a hash of the message is always taken.    If the cryptographic hash is secure then it serves as a proxy for the actual message (which can be of arbitrary length) as one can't change the message without producing a different hash.   Since text messages are short you in theory could sign the message directly however this would be non-standard, it isn't just not supported by the bitcoin source code, it wouldn't be supported by any standard crypto library either.  The message would also need to be less than the n parameter of the curve which for secp256k1 is 256 bits or ~32 bytes (characters).  You could write custom code to implement this but it would be very proprietary, extremely limited, wouldn't be verifiable by any standard library, and I am not sure what you gain over just signing the hash of an arbitrary message.
709  Economy / Trading Discussion / Re: What's the fastest way to buy bitcoin? on: June 17, 2014, 12:42:28 AM
Cool. Thanks for the all the tips. Yeah I'm in the US, so I guess it could be worse, but I don't have an ATM near me Sad

I guess I was looking for something more systematic than localbitcoins, like at ATM-like experience. Guess I'm just going to have to wait until one comes.

If you can send a bank wire you can get bitcoins the same day (usually within an hour of when the funds clear) by using BitSimple ( ).
710  Bitcoin / Legal / Re: Selling a product with BTC inside it on: June 17, 2014, 12:11:45 AM
As long as you keep your transactions below $1,000 per day per person you are not considered to be a MSB

Once again you are completely wrong.  Please stop stating as fact things that you incorrectly believe are true.  Take this from someone who has spent more than you make in a year on legal counsel. There is NO threshold for money transmission.  Note that in your incorrectly quoted section, money transmission is not included in the list for which a min amount applies.  The other categories are referenced by name but money transmission is not.  Did you not find that interesting?  Did you think FinCEN just forgot and happened to name 5 of the 6 categories but not left one out by accident?

What is interesting is you managed to quote the wrong portion of the text when the very next paragraph clearly shows you are wrong.   I guess by pure luck you just happened to not read past the portion you quoted because if you did you would have noticed your error.  Either you have very bad reading comprehension skills or you took a selective quote out of context to support an incorrect statement.  You do understand that someone relying on your false claims could face a felony conviction and potentially decades in prison.   Do you not believe you have an ethical obligation to ensure your statements are correct, property cited, and well researched before making them?

Here is the full content from FinCEN so others can judge for themselves:
Money Services Business - The term "money services business" includes any person doing business, whether or not on a regular basis or as an organized business concern, in one or more of the following capacities:

(1) Currency dealer or exchanger.
(2) Check casher.
(3) Issuer of traveler's checks, money orders or stored value.
(4) Seller or redeemer of traveler's checks, money orders or stored value.
(5) Money transmitter.
(6) U.S. Postal Service.

An activity threshold of greater than $1,000 per person per day in one or more transactions applies to the definitions of: currency dealer or exchanger; check casher; issuer of traveler's checks, money orders or stored value; and seller or redeemer of travelers' checks, money orders or stored value. The threshold applies separately to each activity -- if the threshold is not met for the specific activity, the person engaged in that activity is not an MSB on the basis of that activity.

No activity threshold applies to the definition of money transmitter. Thus, a person who engages as a business in the transfer of funds is an MSB as a money transmitter, regardless of the amount of money transmission activity.

Notwithstanding the previous discussion, the term "money services business" does not include:

A bank, as that term is defined in 31 CFR 1010.100(d) (formerly 31 CFR 103.11(c)), or
A person registered with, and regulated or examined by, the Securities and Exchange Commission or the Commodity Futures Trading Commission.
For the complete regulatory definition of "money services business", see 31 CFR 1010.100(ff) (formerly 31 CFR 103.11(uu)).

Note: Each money services business (MSB) is a financial institution. For the regulatory definition of "financial institution," see 31 CFR 1010.100(t) (formerly 31 CFR 103.11(n)).


Of course that segment is just provided as an overview.  The real regulations are found in 31 CFR 1010.100

(5) Money transmitter—(i) In general. (A) A person that provides money transmission services. The term “money transmission services” means the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means. “Any means” includes, but is not limited to, through a financial agency or institution; a Federal Reserve Bank or other facility of one or more Federal Reserve Banks, the Board of Governors of the Federal Reserve System, or both; an electronic funds transfer network; or an informal value transfer system; or

(B) Any other person engaged in the transfer of funds.
Note a lack of any threshold amount.

711  Bitcoin / Legal / Re: Selling a product with BTC inside it on: June 16, 2014, 11:51:32 PM
If you keep your trades under a certain limit then you don't need to register as a MSB.

This is no different for selling items with "money" inside it then if you sold bitcoin via

Please stop giving "advice".   There is no exempt amount for money transmitters and FinCEN has declared the minting of coins or the exchanging of virtual currency for "real" currency to be a money transmitter.   If you make a 1 satoshi coin it would be money transmission.   Of course you can try to fight it out in court but until you win your "advice" is negligent.

To the OP, the guidance from FinCEN isn't law but rather interpretation of existing law.  It has not been testing in court but understand through the guidance, FinCEN it showing you their gameplan.  Essentially they are saying we believe this activity is regulated because of x, y, and z.   If you engage in that activity and don't follow their regulations you should EXPECT to eventually end up in court.  It shouldn't come as a surprise.  The only reason to do so would be to seek a legal precedent.   Still understand you would be playing with fire.  There are both civil and criminal penalties for violations of the BSA (which FinCEN says applies by the classification of this activity as money transmission).  If you win, FinCEN doesn't really lose anything other than having to scale back the scope of the activities they are able to regulate.  If FinCEN wins, you could potentially lose everything you own, your future income, and even your freedom.   The law isn't always fair.  You should get some competent legal counsel for engaging in activity that an agency says is regulated.  Under the MSB regulations yo have the right to file for an administrative ruling from FinCEN.  In essence you describe in detail your specific business activity and they will clarify if it is regulated or not and why.

Lastly I would say that personally I believe that FinCEN's guidance is contradictory, reaching, and probably extends beyond the scope that the statute was intended.  Of course none of that matters.  If FinCEN convinces an old guy in a black robe that your activity does indeed fall under the scope of the BSA, well that would be very bad so you should at least go in with your eyes wide open.
712  Bitcoin / Development & Technical Discussion / Re: Proof of Hash proposal on: June 16, 2014, 08:37:48 PM
Every miner in the network can know this in a deterministic way. This is the Best Ratio.

The is no unified view of the memory pool between all nodes.  Different nodes may have different views of what txs exist at any point in time.  Say a node publishes a block which has a high score (ratio) for the tx in that block but that block contains tx your node isn't aware of and/or doesn't include some tx that your node is aware of.  Is the block valid or invalid?

One could engage in mining PoH blocks by continually creating a new slightly different tx (and thus different tx hash) to change the hash of the tx set until the miner/attacker finds one which gives it the best ratio and publishing only that block.

If a block is broadcasted at the same time of another different block, and both are valid, the block that has more transactions wins.
Things like this make selfish mining much easier.  I find a block with a very good ratio with all txs and I don't publish it.  I then try to find an inferior but still good enough and publish that one.  Once my competitors start working on the false chain in secret I mine off the better one and if I find a block I publish both back to back.  If I don't find a block I publish the better one before whatever max latency limit passes and I have lost nothing.  Unlike selfish mining where the longest chain wins, I have nothing to lose by engaging in selfish mining.  I have essentially stacked the deck because some blocks are better than others and I can make sure that I always know about the better one.

It is an interesting idea but as presented would be non-deterministic and thus very easy to game.  There would be no reason to "mine" fairly and plenty of incentive to mine unfairly.  This would make reorgs more frequent and deeper and would discount the security of transactions.  6 confirms is considered very secure not because 6 is a magic number but because the probability of reorgs more than 6 blocks deep is very rare unless an attacker has a majority of the hashrate, if reorgs are more frequent and deeper then one would need a higher number of confirmations to have similar assurances of security.
713  Bitcoin / Bitcoin Technical Support / Re: Transaction not broadcasting!!! :( on: June 16, 2014, 08:18:20 PM
If the transaction was not picked up by a miner (malformed, fee too small), then eventually nodes would "forget" it by removing it from their memory pool. Your wallet would recognize this situation and would allow you to re-spend your coins, as otherwise once any coins are sent they would become unspendable by that wallet if they never got confirmed.

That is not correct for all wallets and certainly isn't correct for the OP wallet.

Bitcoin Core v0.9.1.0

The Bitcoin Core wallet will continually attempt to rebroadcast a transaction forever.  It doesn't allow tx which won't be relayed to be created and then assumes it will eventually be included in a block.  There are ways to double spend the original but they user intervention and third party utilities.
714  Bitcoin / Development & Technical Discussion / Re: Delayed transactions (using nTimeLock) on: June 16, 2014, 08:09:33 PM
It seems to me that this still can't be made completely trustless.  The locked-TX that spends the coins back to the depositor must refer to the hash of the most recent TX, which isn't known until it's fully signed.  So it's possible (but obviously unlikely as there's no benefit to green-address signer) that a new locked-TX is never sent and the coins could still end up somehow in limbo.  

It probably would be overly complicated (given the very small window , limited scope, and limited utility of the attack) but one could make this (almost) trustless by having the service sign first.

1) user spends some coins
2) service partially signs first
3) offline user partially signs but doesn't broadcast the tx yet.
At this point only the user has the final tx and hash
4) User provides the service but the hash but the not tx
5) Service creates and partially signs the "refund" ntimelock tx.
6) User verifies the refund tx is valid and broadcasts the tx from #3 to the network.

Even here in theory the service could detect the relayed tx, mutate it and broadcast it to one or more miners hoping that a variant of the tx is what ends up in the block (and thus makes the refund tx invalid) but this is a very difficult attack to pull off as it is very likely the users tx broadcast in #6 will win the race to all miners.  Optimally bitcoin will eventually have immutable txids (can be done via a softfork and then eventually deprecation of non-canonical forms in a future block via a hard fork).   With immutable txs, I am not aware of any attack vector.

I also noticed that the wiki says that the lock_time value will be interpreted as UNIX time rather than block height if lock_time >= 500000000.  Is this supported?

Yes although it goes by block time so keep in in mind block times can be "fudged" by up to two hours.  In most applications this will not be an issue as the locktime will be sufficiently far in the future.  
715  Bitcoin / Development & Technical Discussion / Re: Delayed transactions (using nTimeLock) on: June 16, 2014, 06:29:15 PM
There are two issues with a system like that
a) Bitcoin has no mechanism for detecting the first broadcaster.  Say you hold the tx for five years, and then you broadcast it, the miner including it in a block could simply take credit.  There may be a novel way to avoid this but it isn't a solved problem.  The reverse is also true.  A node could collect a fee in advance but then could simply delete the tx without loss.

b) The fee system is designed to prevent attacks which degrade the performance of the network.  With a finalized tx the tx will eventually end up in a block and thus the network can be assured the fee means a real cost to the user.  An attacker trying to degrade the network would need to a pay a steep fee to do so.   With locktime transactions the fee doesn't guarantee a cost.   A user could spam the network with millions, potentially billions of future txs all with hefty fee and then end up paying for none of them by creating another tx prior to the locktime and broadcasting that making all those held txs invalid and thus the fees promised, never paid.

Still Locktime is a useful tool even when the tx is not relayed.  I will give just one example.  Say I operated a "green address' type site.  You have 1 key, I have 1 key.  The address requires 2 of 2.  I can't spend your coins without your permission and if a merchant trusts me to not approve a double spend then they can trust 0-confirm payments from you.  That would be a very useful service but while I can't steal your funds (2 of 2 remember) I can hold them hostage.  This could be for malicious reasons, governmental interference, or just due to incompetence (if I lose my key your funds are lost forever).  LockTime can be used to end that "stalemate", after each transaction I provide you a future locked tx which sends your coins back to an address you control.   If either one of us loses our key or refuses to sign a tx eventually that locktimed tx will become finalized and you can simply broadcast it to the network to recover your coins.  That LockedTimed tx acts like a "voucher" to recover all your coins in the event of a problem but one which can only be used in the future.  That is just one example but it shows how LockTimed tx don't need to be broadcast to the network prior to their LockTime to be useful.  Other nodes don't need to hold the locked tx because you have a very strong incentive to hold your own locked tx (i.e. in this case it lets you recover your coins).


716  Bitcoin / Development & Technical Discussion / Re: The real cost of transactions on: June 16, 2014, 04:11:10 PM
I think you misinterpreted a prior post of mine.  Danny explains it well in that the subsidy probably is larger than what it needs to be right now, however Satoshi didn't know how fast Bitcoin would increase in value the subsidy simply halves every 4 years.  .  The subsidy is buying about $2M a day in security.  Would Bitcoin be fine with $1M a day, or $300K a day?  Given the current tx volume probably.  

Eventually Bitcoin will need to be supported by tx fees only.  So yes today if the block subsidy went from 25 BTC to zero then one of the following would happen:
a) fees would need to rise to $30 per tx
b) tx volume would need to increase 1000x overnight
c) the hashrate would fall >99% as miners turned off unprofitable hardware

The good news is the subsidy isn't going to zero overnight.  

Now suppose that Bitcoin had no block rewards right now (like it will in the future), there can only be two possible outcomes: either that the hash-rate would drop to much lower levels, and the fees would stay the same. Or that the fees would rise to about $40 per transaction, and that the hash-rate would stay the same.

Or tx volume increases significantly.  In 12 to 15 years, Bitcoin will either be gone or tx volume will be much much higher.  The "$40" number assumes the hashrate (or more correctly the cost of that hashrate) remains the same AND the tx volume remains the same.  avg tx fee * annual tx volume = total miner revenue.  

717  Economy / Speculation / Re: We're not going anywhere, until the 51% question is answered on: June 16, 2014, 03:41:36 PM
Even though ghash is now at 30% I don't think this question is answered at all and this still very much an issue. This is because an attacker could could potentially gain control over more than one pool or more than one pool could collaborate to execute an attack. I would really like to see the pools such that not even any given 5 pools total to 51%. Ideally we get rid of centralized pools altogether or some serious protocol change is made to make it easier to solo mine, or so that 51% attack doesn't work any more alltogether.

It isn't a protocol issue, it is more a human behavior issue and that is a lot harder to "fix".   Logically a miners largest cost is the electrical bill and electrical bills are only due once a month.  Even a pool with 2% of the hashrate will have a 95% confidence to be +/- 10% of the expected revenue after 30 days.   However most miners want a reward now, right now.  That probably isn't going to change. p2pool is a good example.  Right now p2pool shares are ~1000x easier than solo mining however most miners do use it.  Logically even if you radically changed the protocol such that solo mining was 1000x easier most miners would probably not use it. 

Still the risk of 51% attack from pools is overstated.  Lets say right now ghash had 70% of the hashrate.  How would they produce an attack chain?  Well they would need to stop mining the main chain.  ghash on average would go from producing say 8 blocks in a 2 hour period to producing zero.  They can't mine both the main chain and attack chain at the same time.

The risk is small but it could be made even smaller by making it easy for miners to verify they are extending the longest chain.  For example the current block hash of the last block in the longest chain is 0000000000000000302b107dcfdaf35d3b09366638e19aa24ffa91dd7f91d57c and thus all miners should currently be working on a block that extends that block.  Right now if all pool miners are extending block 0000000000000000302b107dcfdaf35d3b09366638e19aa24ffa91dd7f91d57c then you know that no 51% attack is ongoing.  Even if all pools were infiltrated the only thing an attacker could do is steal the mining revenue (by changing the coinbase tx). 

It would be possible to modify the blockheader so that miners (and third party observers) can verify that they are mining the longest legit chain.  This could be done in a backwards compatible manner (won't break existing ASIC hardware) by including a partial block hash of the prior block in the last segment of the block header.  There is limited space in the final segment of the blockheader (the one that the miner adds the nonce and thus must always be provided in full by the pool) so the full blockheader is far too long.  By extending the blockheader and putting the rightmost 8 bytes of the prior blockhash (i.e. 4ffa91dd7f91d57c for the block above) in the last segment it would be easy to spot attempted misuse of miner computing power.  The mining software (using SPV protocol) would maintain an independent record of the longest chain (and the last block extending it) and would verify the work provided by the pool, extends that chain.  If the software detects a scenario where they are not mining the longest chain they would stop mining (or switch pools to a pool that is extending the longest block) and warn the user.   

This type of "verify I am on the longest chain" can be done without a change in the blockheader but it would require pools to send the full blockheader to miners.  For efficiency reasons they don't and that is unlikely to change.  Also if a pool doesn't it can't be forced to do so and most miners wouldn't see a lack of the verifying information as sufficient reason to not use the pool.  Changing the blockheader would ensure the necessary information is always sent to the miner.
718  Bitcoin / Development & Technical Discussion / Re: Question on DER-encoding of signature pair (r, s) on: June 15, 2014, 09:30:22 PM
As piotr_n pointed out the bitcoin expects the highest bit to be zero so if it isn't an extra zero byte is added.  This means that r & s will always be 32 or 33 bytes.  Don't quote me but I believe this is a bug in OpenSSL which was copied and now everyone has to keep the bug in the code to ensure it remains compatible.

You can't think of a signature as a curve point (x,y), right?  A signature is a pair of 256-bit numbers (r,s), not a point on secp256k1.
Correct. A point in computed in the creation of the signature (k x G) but it is not the signature itself.  r & s are not an x & y value. 

Did I mark-up the image correctly (r comes before s)?

If I know r and s as 256-bit integers (big numbers), how exactly do I DER encode them?

You will also need to know the sighash.  Given r,s, and sighash they are arranged in the following order:
<Len_sig><sequence = 0x30><len_rs><integer = 0x02><len_r><r_value><integer 0x02><len_s><s_value><sighash>

All elements are 1 byte except r & s which will be 32 or 33 bytes.  Also be sure to read up carefully on sighash because it is "moved" (for reasons that are beyond me).  Another Satoshi-ism I guess.

r_value = Convert r into a little endian byte array.  If the leading bit is not zero then prepend a zero value byte.
s_value = Convert s into a little endian byte array.  If the leading bit is not zero then prepend a zero value byte.
r_len = number of bytes for  r (always 20 or 21)
s_len = number of bytes for s (always 20 or 21)
sequence = always 0x30
integer = always 0x02
len_rs = r_len + s_len + 2 (two extra bytes for the two integer bytes)
len_sig = len_rs + 3 (three extra bytes for the len_rs byte, the sequence byte and the sighash byte

What follows next is whatever is needed to complete the script which is encumbering the outputs.  The PubKey then follows when redeeming Pay2PubKeyHash outputs but is not universally present in other output types (i.e. Pay2PubKey).  

An aside: Besides DER being the standard format of OpenSSL, is there really any benefit to DER encoding?  It seems to me we could simply pack r and s and have all signatures exactly 64 bytes long. 

Correct.  There is very little reason to use DER encoding other than satoshi did it that way.  A new version of the tx format could created which is more space efficient.  The major advantage of DER encoding is sharing information between incompatible systems.  It is excessively verbose to facilitate a data interchange.  Putting DER signature inside propreitary data makes no sense.  Knowing DER doesn't allow you to decode a Bitcoin tx, and if you can decode a Bitcoin tx you could just follow explicit rules to decode r,s, sighash, pubkeys, etc just like you need to follow explicit rules to decode the tx version, number of inputs, sequence, etc.

719  Bitcoin / Bitcoin Technical Support / Re: Re: Bitcoin-QT client question on: June 15, 2014, 07:41:33 PM
I am not saying an invalid TX, but a TX with a invalid output (the technical term may be unspendable output - an output in which it would be impossible for private keys to be associated with).
Once again an unspendable output isn't an output that is invalid, it is an output that is invalid.  An invalid output means an invalid tx, and any block including it would be an invalid block and thus never part of the longest chain.  For example a native multisig output which is greater than 3 of 3 is invalid.  It will never be included in a block.

Unspendable =/= Invalid.  Unspendable is just unspendable.  It could be unspendable on purpose ("burning coins" or by accident (wallet software errors) but it is unspendable all the same.


"height" : 305997,
"bestblock" : "00000000000000005c56379fc24b9b75c5c44c7afdb75f0c5b0801c56ec4f6bf",
"transactions" : 3305419,
"txouts" : 11452422,
"bytes_serialized" : 396365647,
"hash_serialized" : "10c14635b7ca03524099eb1bef0018480afddb67986b569fc9aa58bf1d16bb73",
"total_amount" : 12899789.79002854

To date 135.20997146  BTC have been destroyed.
(305997-210000)*25 + 210000*50 = 12899925.00000000 BTC
12899925.00000000 - 12899789.79002854 = 135.20997146

What my question is, how is a pool destroying coins by sending part of the block reward to an unspendable output different from broadcasting a TX with an unspendable output (with your own coins)

I have no idea what you are talking about.  An unspendable output is an unspendable output no matter who creates it.  Nobody said anything about a pool creating an unspendable output.
720  Bitcoin / Bitcoin Technical Support / Re: Re: Bitcoin-QT client question on: June 15, 2014, 04:42:50 PM
Wouldn't this essentially be the same as sending a TX with an invalid output?

On the off chance that your response wasn't just affiliate spam, there is a difference between an invalid tx and an unspendable output.  An invalid tx is simply dropped from the network.  It will never become part of a block and thus the coins will never be destroyed.  An example would be a tx which has 1BTC in inputs and a 1.1 BTC output.  That is an invalid output.   To destroy coins requires an unspendable output.  OP_RETURN is a valid but unspendable output.
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 ... 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!