Bitcoin Forum
April 21, 2014, 05:14:57 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  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 ... 190
581  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 17, 2013, 06:28:52 PM
it makes it nearly impossible to create a alternative client, when the "standard" mutates all the time. bitcoin needs diversity in clients.
Would you like to only be able to use internet explore? sure it would work good. but really?

The standard does not mutate all the time (though I do agree client diversity is a good thing).

It mutates with every commit to the satoshi client repo. Code is not a standard.

No, it really doesn't.

Sipa's patch last year changed how this particular implementation behaves, only.  It was not a change in the protocol.  The change was not binding on anyone else.

P.S.  The standardization thing is discussed in endless detail in many other threads.  Please read some of those before posting again.  You have contributed nothing new to the debate; even your pointless personal attacks are reruns.
582  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 17, 2013, 04:30:32 PM
Quote
Code:
       assert 1 == ssl.ECDSA_sign(0, hash, len(hash), mb_sig, ctypes.byref(sig_size0), self.k)
        return mb_sig.raw
I believe this code is wrong.

ECDSA_sign takes a pointer siglen for the length of the buffer. The reason it passes a reference there and not a value is because it writes the resulting length back to it. Otherwise there would be no way to know the length other than the maximum since, obviously, char * doesn't encode a size.  Your code appears to do nothing with the returned size. This is wrong, and it means you're reading past the end of the destination array. Be glad the additional space contains only zeros and not your private key.

pwn3d
583  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 17, 2013, 04:07:39 PM
@kokjo: mind sharing the code how to embed the OpenSSL-created signature into a sigScript? I expect the problem is caused by how you wrap/pad it, rather than with the signature itself.
Code:
sc = [script.OP_PUSH(sig+"\x01"), script.OP_PUSH(key.publickey)]
tx.inputs[0].script = script.encode_script(sc)

as said before its the statoshi clients problem, not me generating bad(wrongly padded) signatures. i already have tracked down the problem in the satoshi client.

I decoded the transaction you provided by hand.  It is wrong, and I told you where it was wrong.

The satoshi client is only broken if you got that hex as the output of signrawtransaction.
584  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 17, 2013, 03:22:35 PM
Well, good luck with that, I guess.
so you are okay with that the developers is destroying bitcoin by trying to make it better?

Destroying?  Nonsense.

Leave your hyperbole at home and go read up on why non-canonical encodings are bad, and why the developers decided to mark them as non-standard.  (That the satoshi client refuses to emit anything it considers to be nonstandard should be obvious.)
585  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 17, 2013, 03:03:41 PM
you don't have to tell my where my perfectly valid transaction fails bitcoind's beauty check, you need to remove the check from the satoshi client and stop adding useless crap to it.

the signature was generated with openssl, and is perfectly valid, my client and blockchain.org agrees.
The satoshi client should not be the protocol standard, of cource i could fix my transaction and give you people a free pass to fuck around more with bitcoin.

I will not allow this, and i object to the elitist culture among the main developers.

fix bitcoin, go make a standard and stick to it.

Well, good luck with that, I guess.
586  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 17, 2013, 02:44:27 PM
You have two bytes of padding in there.

You may want to look at the bitcoind code to see how it gets unpadded signatures.

Code:
6c - script length
49 - signature length - should be 47 once the padding is removed
30 - marker
44 - rs length <total_length>
02 - marker
20 - R length
3ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37 - R
02 - marker
20 - S length
14247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c5173 - S
00 - garbage - invalid
00 - garbage - invalid
01 - SIGHASH flag
21 - pubkey length
02 - pubkey is compressed and even
0c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95 - pubkey
587  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 17, 2013, 02:00:25 PM
there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:
Code:
0x30  <total_length> 0x02 <length_of_R> <R> 0x02 <length_of_S> <S> <hashtype>

it is taken using this expression:
Code:
unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

This distinction is only meaningful when the signature is not canonical.  When the signature is in the proper form, the last bye is the last byte.


I'm having a hard time understanding what you are talking about here.  The SIGHASH values apply to signatures.  The txout being redeemed has no bearing on them.
588  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 17, 2013, 01:43:47 PM
Would you mind posting the hex of the signed raw transaction?

I was just looking in script.spp, and this error is caused by an incorrect length.  When you attach your hashtype, are you changing the total length?

0x30  <total_length> 0x02 <length_of_R> <R> 0x02 <length_of_S> <S> <hashtype>
589  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 17, 2013, 01:18:50 PM
BITCOIN IS SHIT, it does not accept signatures from the most well know implementation of crypto algorithms: openssl.

Code:
ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa

why the fuck is this stuff implemented the way it is?

bitcoin and especially the satoshi client is a stinking pile faulty patches on other patches of bad and stupidly written code!

All main developers is bad at coding, and should feel bad about it.

/rant over

What's funny is that this very thread explains why non-canonical signatures are bad, and why we stopped accepting them.

Just out of curiosity, is openssl giving you a padded signature under normal circumstances, or are you going out of your way to make it give you garbage?
590  Bitcoin / Hardware / Options for dealing with Avalon? on: July 16, 2013, 05:06:41 AM
Now that Avalon batch #2 (and #2.5) has "finished shipping" according to the newsletter, I feel that the time has come to really push on my missing orders.  I know that some batch #1 people are still missing units, and you guys have my sympathy.  You guys missed out on a fortune.  I merely missed out on cost recovery.

I placed two orders on February 3rd (batch #2), and paid through walletbit.  One was as a guest, and the other was using funds sent to my walletbit account.

Walletbit confirmed both orders (batch #16633 and #16813).  Walletbit support confirmed my contact (shipping) information.

Quote
I can confirm that those TXIDs, your name and email address match. This means everything has processed correctly and Avalon has received the correct information for your order. I have just sent confirmation emails for the newest transaction on each purchase. Please register with Avalon support for further instructions on your order. They are integrating purchases from their old shopping cart into their new one. When this happens, confirmation emails will be automatically sent from their new shopping cart as well.

If anyone is curious, the transactions are here:
https://blockchain.info/tx/099f523d5e9b21fca9d9f71b4f261a82ac0a56e3672d80680038071cfdf689cc
https://blockchain.info/address/1MMdh3JTRTDX3MvvYTaEmAnejjmtdEAqxc

The second one is an address instead of a transaction because I had to send multiple payments.  Walletbit considers the final payment to be the TXID.

My orders do not appear in the Avalon store.

I have two tickets open with Avalon.  Ticket # 806 from May 13th, and ticket # 1136 from June 22nd.  Both tickets mention that there are two orders, and each contains the transaction ID of one order.  Neither ticket has been updated.

I sent one PM on these forums, and BitSyncom has been online since then.  I have called the phone number listed at the bottom of the June 12th newsletter email several times, with no answer.

I have waited patiently while they were shipping, hopeful that I would hear something.

I've argued several times that incompetence and negligence don't constitute a scam, so I can't go to the scam thread to ask that the account get marked.
I could give them a negative trust rating (-4, counting the value), but no one will ever see it unless Theymos adds me to the DefaultTrust list (unlikely).
I could start posting this story in every thread about Avalon.  I've posted it in a few, when it seemed on topic, and in a few topics specifically about missing orders.  But I don't want to be a nuisance to everyone.  Hell, I don't even want to be a nuisance to BitSyncom, I just want this fixed.

What options do I really have now?

Note that I'm looking for options short of invoking the legal system.  I'd never collect a civil judgment, and all a criminal complaint (grand theft) would do is ban Yifu from attending conferences in the US.
591  Bitcoin / Development & Technical Discussion / Re: Increase currency divisibility with soft-fork on: July 16, 2013, 04:08:52 AM
Please don't just scream "no data in script". Provide some technical reasons for that.

There are so many data manipulating OP codes in script, so I don't think scripts were not supposed to store any data.

Whether we will need to worry about this, or whether we will become very rich, is irrelevant to this technical discussion

I would think that the nearby field named "value" that is used to store the value of a vout is a very good technical reason not to have a "paravalue" field.  Incidentally, this is the exact same technical reason why IPv6 wasn't implemented by adding address fields to TCP.  Ok, so maybe IPv6 as an example makes your case instead of mine, but if we ignore the politics and look at the technology, I think I still come out ahead.

Upon further contemplation, I think that IPv6 is the right example.  The IPv4 shortage is now something like 20 years old.  If they had just decided in the 90s to pick a date in the far future, like 2005 or something, and just forced everyone to switch, IPv4 would just be a fading memory now.  Instead, they squandered years (and probably billions of dollars) on crutches.

Also, we have a tendency to call the end of the transaction by the odd name "script".  As if "script" was the end instead of the means.  If we made a point to call it "redemption criteria", people would at least look a bit guilty when they try to stash random stuff in it.
592  Bitcoin / Development & Technical Discussion / Re: Increase currency divisibility with soft-fork on: July 16, 2013, 03:07:31 AM
The script is the absolute worst place imaginable to tinker with value.

Script is the only place to include arbitrary data and get signed. I can't see any other option without a hard-fork.

I'm well aware of that.  It is still the worst place for it.

And think about it in context.  This is a soft fork in name only.  If it was needed for economic reasons, everyone would need to upgrade anyway.  Might as well do it hard so that the people left behind know that they've been left behind.

Since it is the ONLY place for it, so I can argue it is the BEST place for it.

Any old clients will work as usual without upgrade. They just can't send and receive sub-satoshi payment. There needs to be new block version and tx version for such upgrade. The client should give a warning when it sees a flooding of blocks and txs of unknown version, so people will know there are some new rules on the network.

I disagree.  Script nonsense is the ONLY place for it, the WORST place for it, and the BEST place for it, all at once.  Very clear indication to stay the hell away.  I'd prefer a hard fork any day.

Since the script can contain arbitrary data, we could shovel all sorts of garbage into it.  And it isn't like people haven't suggested plenty of crap already*, or that they won't go on to dream up much more.  Best not to tempt them, particularly not with something that already has an actual field.

At any rate, none of us will ever need to worry about it.  If the value grows so fast that we need to change the scaling factor for economic reasons before we want to do it for aesthetic reasons**, we'll all be so rich we can hire people to do it for us.

* Yes, I'm looking at you, colored coin scheme de jour.

** Daddy, why did Satoshi make the value field so narrow?  My Speak & Spell has 128 bit registers.
593  Bitcoin / Development & Technical Discussion / Re: Increase currency divisibility with soft-fork on: July 15, 2013, 06:09:08 PM
The script is the absolute worst place imaginable to tinker with value.

Script is the only place to include arbitrary data and get signed. I can't see any other option without a hard-fork.

I'm well aware of that.  It is still the worst place for it.

And think about it in context.  This is a soft fork in name only.  If it was needed for economic reasons, everyone would need to upgrade anyway.  Might as well do it hard so that the people left behind know that they've been left behind.
594  Bitcoin / Development & Technical Discussion / Re: Increase currency divisibility with soft-fork on: July 15, 2013, 05:18:34 PM
The script is the absolute worst place imaginable to tinker with value.
595  Bitcoin / Development & Technical Discussion / Re: Decoding Block Index 0 on: July 13, 2013, 05:44:08 AM
I find it funny how we are arguing about 50 bitcoins that is owned by a person who probably has more than a million.

Then you should probably read the thread again.  It isn't about the coins, it is about making sure that the entire network treats those coins in the same way if they ever move.
596  Bitcoin / Bitcoin Discussion / Re: what do you think about bitcoin hashing function? on: July 13, 2013, 02:05:30 AM
Uh...

Difficulty and nonce are related in such a way that it takes roughly difficulty*232 hashes on average to find a valid block.  Meaning that when the difficulty is 25 million, like it is now, then of every 25 million iterations through the entire 32 bit nonce space, you will find one hash that meets the target criteria.  If that is what you mean by "failing", then we are doing it constantly.

The stock client has used extraNonce forever (at least for the last 2 years that I've been paying attention).  But there are several other variables in the header that can change along the way, and every miner uses them.

What I mean failing is that given a block header, by hashing from nonce 0 to nonce  2^32, no hash value less than the number required by current difficulty.

Yes, and today, we are failing about 25 million times every 10 minutes.  Difficulty is the number of times that we expect to fail in that task for each block.
597  Bitcoin / Bitcoin Discussion / Re: what do you think about bitcoin hashing function? on: July 12, 2013, 11:21:25 PM
Uh...

Difficulty and nonce are related in such a way that it takes roughly difficulty*232 hashes on average to find a valid block.  Meaning that when the difficulty is 25 million, like it is now, then of every 25 million iterations through the entire 32 bit nonce space, you will find one hash that meets the target criteria.  If that is what you mean by "failing", then we are doing it constantly.

The stock client has used extraNonce forever (at least for the last 2 years that I've been paying attention).  But there are several other variables in the header that can change along the way, and every miner uses them.
598  Bitcoin / Hardware / Re: Avalon ASIC Batch 2 Problem Orders (Bitsyncom PLEASE Help) on: July 12, 2013, 05:37:57 PM
Reposted at sneef's request:
I have two orders from February 3rd, neither of which is showing in the store.  I also have two tickets in their system, neither of which has been answered.

Ticket #806 opened May 13th
Status: ignored
Problem: order not appearing in store

Ticket #1136 opened June 22nd
Status: ignored
Problem: order* not appearing in store.  ( * Because of wallet dust, I had to break this payment into several parts.  Walletbit uses the final txid as their reference.  Check the address history to see that I really did send 75 BTC.)

Walletbit confirmed both orders.
599  Bitcoin / Hardware / Re: Avalon batch [2] countdown! on: July 12, 2013, 07:43:19 AM
While we are at it...

Can you look at tickets 806 and 1136?  Two orders from February 3rd, confirmed by walletbit, neither appearing in the store.
600  Bitcoin / Hardware / Re: Avalon ASIC users thread on: July 12, 2013, 02:25:14 AM
Does anyone have a useful means of contacting Avalon?

I have two orders from February 3rd, neither of which is showing in the store.  I also have two tickets in their system, neither of which has been answered.

I waited patiently when batch 2 was delayed for everyone.  But now that they are talking about batch 3 shipping, I'm pissed.

if your tickets are older than June they will be ignored, if they are, create a new one.  yifu has said this many times Smiley

Yup, that's why I made the second ticket.
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 ... 190
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!