Bitcoin Forum
April 23, 2014, 01:08:22 PM *
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  Other / Meta / Re: Proposal: activity penalty for necroposts on: July 18, 2013, 03:21:08 PM
I see a lot of 2011 and 2012 threads getting new posts, usually by relatively new users making lots of short (one or two line) posts.

Giving a permanent -10 penalty to activity rating would make this activity useless for people hoping to boost their activity for PM or trust purposes, but not be overly punitive for people that really think that an old thread deserves a new read.

Also, I mentioned it in a different thread, but figure it is worth repeating here.  Ignores earned should deduct from activity, either actual activity or effective activity used for spamming.

You're assigning some arbitrary value to that number on the left there again. Like people did with the postcount. Which was the reason why postcount got removed in the first place.

Here is a Public Service Announcement: Penis size is unrelated to either activity or postcount size. No one cares about activity or postcount size. If you DO care aout activity or postcount size nonetheless, please stay calm, sit down in a quiet place and wait for help to arrive. A unit of helper monkey will be dispatched as soon as possible.

You might not have gotten the memo, but the ability to send PMs is linked to penis size activity.
582  Other / Meta / Proposal: activity penalty for necroposts on: July 18, 2013, 02:55:28 PM
I see a lot of 2011 and 2012 threads getting new posts, usually by relatively new users making lots of short (one or two line) posts.

Giving a permanent -10 penalty to activity rating would make this activity useless for people hoping to boost their activity for PM or trust purposes, but not be overly punitive for people that really think that an old thread deserves a new read.

Also, I mentioned it in a different thread, but figure it is worth repeating here.  Ignores earned should deduct from activity, either actual activity or effective activity used for spamming.
583  Economy / Speculation / Re: 2 Scenarios resulting from SD: Bearish vs. Turbo Bearish with Lasers on Top on: July 18, 2013, 02:43:33 PM
Why do people with shares in SD suddenly feel compelled to turn them into fiat?

Exactly.

This idea has been almost the sole reason for the sudden price drop, and I think that's simply not the case.

To a first approximation, everyone talks their book.  They start with a conclusion and then try to justify it.  Everything in the speculation forum is either post-hoc logic, or voodoo (chart analysis).
584  Bitcoin / Development & Technical Discussion / Re: New Attack Vector on: July 18, 2013, 05:21:49 AM
i dare you give me a piece of c code(10-20 lines) that i can't explain.

Okay, I'll give you an easy one. How about two statements?
[...]
An implementation of f() constructed from your English description must produce identical results for all possible val and l on the range 0-31 inclusive.

a function f is given 2 arguments, one integer named l and and a 32-bit unsigned integer named val and returns a 32 bit unsigned integer.
if the value of l is strictly larger then 16 we reassign the variable val to the sum of:
val shifted l minus 16 to the left(or is it right? im left-right confused!)
the lower l minus 16 bits of val plus 2 to the l - 16 power minus 1, shifted l - 16 times to the left
if the value of l is less or equal to 16 set val to itself shifted 16  - l times to the right
return val
But what you're not understanding the function. All you're doing is repeating it word for word. He meant you couldn't explain it colloquially.

i dare you give me a piece of c code(10-20 lines) that i can't explain.

Okay, I'll give you an easy one. How about two statements?
[...]
An implementation of f() constructed from your English description must produce identical results for all possible val and l on the range 0-31 inclusive.

but no i have no idea of what the code is doing, but it seems like some insanely optimized bit twiddling computation, its probably a estimation of some mathematical function. I really dislike bit twiddling magic, its just as incomprehensible as brainfuck or APL.
hey look, gmaxwell delivered and you failed.
its a part of a code that computed a overestimate of log_2

An overestimate of log2 is easy.  It doesn't need two parameters...
585  Bitcoin / Bitcoin Discussion / Re: Bitcoin Address Collisions. on: July 18, 2013, 05:15:59 AM
i laugh at people who think they are math experts.

there are 2 (followed by 160 zero) possible combinations.. some of you naively believe that if you start at 1 and count upwards it would take 2(followed by 160 zero's) to find a collision.

this would only be the case if the addresses were made in lets say Hex of all F's..

but in reality ITS RANDOM

the addresses can be ANYWHERE between 1 and 2 (followed by 160 zero's).

meaning its just as likely that a randomiser picked 10 as it would pick 100,000,000,000,000.

with an estimated 84mill addresses being used, there is a chance that one of these 'used' addresses is randomised in the low range.

put simply

its random. they are not all clumped up at the far end of the spectrum.

to add to that depending on the degree (amount of significant figures) were used before hashing and converting, can far reduce the potential 'luck'.

this is why i feel the bitcoin foundation are rightly so in adding the new feature for version 0.9 of bitcoin-QT to not require random addresses per transaction.

Just FYI, 2160 != 2*10160.

Also, 'random' is a double-edged sword. What you gain by having keys fail to cluster near the far end, you lose by having to check each one.
586  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.
587  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
588  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.
589  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.)
590  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.
591  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
592  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.
593  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>
594  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?
595  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.
596  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.
597  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.
598  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.
599  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.
600  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.
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!