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.) |
|
|
|
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. |
|
|
|
You have two bytes of padding in there. You may want to look at the bitcoind code to see how it gets unpadded signatures. 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
|
|
|
|
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: 0x30 <total_length> 0x02 <length_of_R> <R> 0x02 <length_of_S> <S> <hashtype> it is taken using this expression: 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. |
|
|
|
|
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>
|
|
|
|
BITCOIN IS SHIT, it does not accept signatures from the most well know implementation of crypto algorithms: openssl. 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? |
|
|
|
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. 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/099f523d5e9b21fca9d9f71b4f261a82ac0a56e3672d80680038071cfdf689cchttps://blockchain.info/address/1MMdh3JTRTDX3MvvYTaEmAnejjmtdEAqxcThe 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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
The script is the absolute worst place imaginable to tinker with value.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
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  Yup, that's why I made the second ticket. |
|
|
|
You can't just do a straight division.
That's why I wrote, "the next address generated", not "probability that any two addresses collide". Approximate probability of collision between any two addresses can be calculated the following simple way: obviously, the first address can't collide with another address, probability for the second to collide with the first is 1/2^160, for the third it is 2/2^160, 4'th 3/2^160, it is easy to see, that it is an arithmetical progression. Total probability that any two addresses collide approximately equals the sum of the progression, and can be written as: P = n^2/2^ 161, where n - is the amount of bitcoin addresses in use. For 2.1*10^15 addresses it gives us: 1.5*10^-18 This calculation is simplified a bit. However, the result should be very close to the exact result. The forum supports superscripts. P = n 2/2 161 |
|
|
|
...insider trading either, which is exactly what I think goes on with Bitcoin.
LOL. Good bye. |
|
|
|
|
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.
|
|
|
|
|
Show Posts
