Topic: Who is creating non-DER signatures? (Read 2502 times)
Perhaps the iPhone app was never updated.
Some old versions of bitcoinjs and Armory are known to have produced non-DER signatures, but both authors are aware of this, and fixed their code more than half a year ago, afaik.
The Java library from two years ago is bitcoinj and the author was me. I tried making Bouncy Castle produced negative r/s values a while ago by letting it generate signatures over random data in a tight loop, but it never created any. Maybe we should try the same thing with bitcoinjs
Question, if these address contain too many characters, why don't miners reject the txs or blocks that contain them. Would the database schema limit the output field to 40 char?
They simply pass them to OpenSSL. OpenSSL says that the keys are ok, so the miner accepts the block.
Looks like this are transactions produced with a java client,
i don't know what java client implementations exists, but looks like at least there is one to send bitcoins.
so is either bitcoinj or one of the outdated java versions .
i will bet some of this webpages that steals your mtgox account
may be using a java exploit.
http://techcrunch.com/2013/04/11/mt-gox-cross-site-scripting-attack-wipes-out-bitcoin-accounts/
i say cut them out and maybe send a message to the bitcoinj project to fix it.
i don't know what java client implementations exists, but looks like at least there is one to send bitcoins.
so is either bitcoinj or one of the outdated java versions .
i will bet some of this webpages that steals your mtgox account
may be using a java exploit.
http://techcrunch.com/2013/04/11/mt-gox-cross-site-scripting-attack-wipes-out-bitcoin-accounts/
i say cut them out and maybe send a message to the bitcoinj project to fix it.
Didn't a googler put out a java client 2 years ago? Or was that just a java miner? probably breaking b/c some packages updated and code was not fixed to conform to address rules.
Question, if these address contain too many characters, why don't miners reject the txs or blocks that contain them. Would the database schema limit the output field to 40 char?
So bitcoinjs can do this? I thought we looked at it before and ruled that out. Maybe someone should send a message to Ben (piuk) and ask him to look at the thread.
If the transactions ARE created by blockchain.info, then presumably he will be able to check that.
If the transactions ARE created by blockchain.info, then presumably he will be able to check that.
I mailed him personally about it, but didn't get an answer (yet).
So bitcoinjs can do this? I thought we looked at it before and ruled that out. Maybe someone should send a message to Ben (piuk) and ask him to look at the thread.
If the transactions ARE created by blockchain.info, then presumably he will be able to check that.
If the transactions ARE created by blockchain.info, then presumably he will be able to check that.
Dafuq?
I'm using blockchain.info and the iphone app. What's going on here?
In Dummy Talk plz
I'm using blockchain.info and the iphone app. What's going on here?
In Dummy Talk plz
Scanning the list of addresses I noticed a vanity address:
1RedditJvM5nTLZvoX2UyURhWtwzRDrsg
Googling it you get to:
http://www.reddit.com/r/Bitcoin/comments/14vcj4/my_reddit_address/
That at least gives a reddit user to ask: http://www.reddit.com/user/pheenix99
As soon as I have posted this I will send him a reddit message with the url of this thread.
edit: well I tried but kept getting HTTP 502 errors (bad gateway) from the reddit site.
1RedditJvM5nTLZvoX2UyURhWtwzRDrsg
Googling it you get to:
http://www.reddit.com/r/Bitcoin/comments/14vcj4/my_reddit_address/
That at least gives a reddit user to ask: http://www.reddit.com/user/pheenix99
As soon as I have posted this I will send him a reddit message with the url of this thread.
edit: well I tried but kept getting HTTP 502 errors (bad gateway) from the reddit site.
Hi Pheenix99,
There are a few thousand transactions on the blockchain that are a bit unusual, but people don't know exactly what software is creating them. It does not sound like you are using any software that is out of the ordinary so I would not worry about it.
Jim
Why not simply declare certain deviations from DER as valid in Bitcoin transactions for the purpose of the protocol spec, and put code in the client to automatically convert these to DER before sending them off to OpenSSL, so the behavior of accepting these deviations is canonized in the Bitcoin spec instead of being a weird dependency on OpenSSL behavior?
Since these already exist in transactions anyway, the specification is already going to have to allow these explicitly, or else the existing blocks can't validate. The way I see it, adding a new constraint going forward serves no useful benefit if a complete Bitcoin implementation must already tolerate these anomalies just to validate the existing data set.
Since these already exist in transactions anyway, the specification is already going to have to allow these explicitly, or else the existing blocks can't validate. The way I see it, adding a new constraint going forward serves no useful benefit if a complete Bitcoin implementation must already tolerate these anomalies just to validate the existing data set.
By banning those deviations, and putting code to ban them in the reference client used by miners, we can eventually ensure that the blockchain never has such deviations present other than in old history. Once that old history is protected by a checkpoint, nodes can safely skip the verification of the signatures entirely because the fact that the signatures are in the canonical blockchain implies they must be valid.
Sure you'll want to keep the backwards compatible code in the reference client used by miners so they can validate without checkpoints, but that means other implementations don't have to carry that baggage forward. I pointed out in the pull-req that Bitcoin clients will eventually run on all sorts of stripped down secure hardware stuff like smartcards and HSM's which often have downright anemic performance. Being able to avoid OpenSSL dependencies will make developing those clients much easier.
Fair enough. I'm sold.
Why not simply declare certain deviations from DER as valid in Bitcoin transactions for the purpose of the protocol spec, and put code in the client to automatically convert these to DER before sending them off to OpenSSL, so the behavior of accepting these deviations is canonized in the Bitcoin spec instead of being a weird dependency on OpenSSL behavior?
Since these already exist in transactions anyway, the specification is already going to have to allow these explicitly, or else the existing blocks can't validate. The way I see it, adding a new constraint going forward serves no useful benefit if a complete Bitcoin implementation must already tolerate these anomalies just to validate the existing data set.
Since these already exist in transactions anyway, the specification is already going to have to allow these explicitly, or else the existing blocks can't validate. The way I see it, adding a new constraint going forward serves no useful benefit if a complete Bitcoin implementation must already tolerate these anomalies just to validate the existing data set.
By banning those deviations, and putting code to ban them in the reference client used by miners, we can eventually ensure that the blockchain never has such deviations present other than in old history. Once that old history is protected by a checkpoint, nodes can safely skip the verification of the signatures entirely because the fact that the signatures are in the canonical blockchain implies they must be valid.
Sure you'll want to keep the backwards compatible code in the reference client used by miners so they can validate without checkpoints, but that means other implementations don't have to carry that baggage forward. I pointed out in the pull-req that Bitcoin clients will eventually run on all sorts of stripped down secure hardware stuff like smartcards and HSM's which often have downright anemic performance. Being able to avoid OpenSSL dependencies will make developing those clients much easier.
Why not simply declare certain deviations from DER as valid in Bitcoin transactions for the purpose of the protocol spec, and put code in the client to automatically convert these to DER before sending them off to OpenSSL, so the behavior of accepting these deviations is canonized in the Bitcoin spec instead of being a weird dependency on OpenSSL behavior?
Since these already exist in transactions anyway, the specification is already going to have to allow these explicitly, or else the existing blocks can't validate. The way I see it, adding a new constraint going forward serves no useful benefit if a complete Bitcoin implementation must already tolerate these anomalies just to validate the existing data set.
Since these already exist in transactions anyway, the specification is already going to have to allow these explicitly, or else the existing blocks can't validate. The way I see it, adding a new constraint going forward serves no useful benefit if a complete Bitcoin implementation must already tolerate these anomalies just to validate the existing data set.
Dafuq?
I'm using blockchain.info and the iphone app. What's going on here?
In Dummy Talk plz
I'm using blockchain.info and the iphone app. What's going on here?
In Dummy Talk plz
Scanning the list of addresses I noticed a vanity address:
1RedditJvM5nTLZvoX2UyURhWtwzRDrsg
Googling it you get to:
http://www.reddit.com/r/Bitcoin/comments/14vcj4/my_reddit_address/
That at least gives a reddit user to ask: http://www.reddit.com/user/pheenix99
As soon as I have posted this I will send him a reddit message with the url of this thread.
edit: well I tried but kept getting HTTP 502 errors (bad gateway) from the reddit site.
1RedditJvM5nTLZvoX2UyURhWtwzRDrsg
Googling it you get to:
http://www.reddit.com/r/Bitcoin/comments/14vcj4/my_reddit_address/
That at least gives a reddit user to ask: http://www.reddit.com/user/pheenix99
As soon as I have posted this I will send him a reddit message with the url of this thread.
edit: well I tried but kept getting HTTP 502 errors (bad gateway) from the reddit site.
Scanning the list of addresses I noticed a vanity address:
1RedditJvM5nTLZvoX2UyURhWtwzRDrsg
Googling it you get to:
http://www.reddit.com/r/Bitcoin/comments/14vcj4/my_reddit_address/
That at least gives a reddit user to ask: http://www.reddit.com/user/pheenix99
As soon as I have posted this I will send him a reddit message with the url of this thread.
edit: well I tried but kept getting HTTP 502 errors (bad gateway) from the reddit site.
1RedditJvM5nTLZvoX2UyURhWtwzRDrsg
Googling it you get to:
http://www.reddit.com/r/Bitcoin/comments/14vcj4/my_reddit_address/
That at least gives a reddit user to ask: http://www.reddit.com/user/pheenix99
As soon as I have posted this I will send him a reddit message with the url of this thread.
edit: well I tried but kept getting HTTP 502 errors (bad gateway) from the reddit site.
What Gavin merged yesterday simply makes those signatures fail the IsStandard() test, however blocks including such signatures are still accepted.
That makes more sense.
What about introducing a soft fork rule that those transactions can only be incorporated into blocks with height = 0 mod 256 for a while. Alternatively, it could start at 16 and double every 2 weeks until it hits .
This still lets people transfer their coins, but encourages them to move them to compliant clients.
This still lets people transfer their coins, but encourages them to move them to compliant clients.
There isn't really any need for that kind of complexity. What Gavin merged yesterday simply makes those signatures
EDIT: I was mistaken: the change is also present on testnet. It's not an IsStandard() thing but rather a test that prevents the transactions from entering the mempool.
.... we're trying to introduce a rule to make such non-standard signatures invalid. Obviously, that can't be done as long as any significant amount of clients on the network is creating these.
If it is a small enough number, then maybe it is not such a big deal?
Quote
I've monitored all transactions the past weeks (1.4M transactions), and it seems 9641 of them contain at least one non-standard signature.
That means that only 0.7% of transactions use non-DER signatures.
What about introducing a soft fork rule that those transactions can only be incorporated into blocks with height = 0 mod 256 for a while. Alternatively, it could start at 16 and double every 2 weeks until it hits
This still lets people transfer their coins, but encourages them to move them to compliant clients.
It would probably immediately cause a thread to be started asking why it is taking ages to move coins and then find out what software they are using.
Once a patch is available for their client. The soft fork rule could be updated for very strict encoding. A sub-set of DER would be best, if it can be expressed in a few sentences. It's pretty much a byte type id and then one or two large numbers.
Looks like this are transactions produced with a java client,
i don't know what java client implementations exists, but looks like at least there is one to send bitcoins.
so is either bitcoinj or one of the outdated java versions .
i will bet some of this webpages that steals your mtgox account
may be using a java exploit.
http://techcrunch.com/2013/04/11/mt-gox-cross-site-scripting-attack-wipes-out-bitcoin-accounts/
i say cut them out and maybe send a message to the bitcoinj project to fix it.
i don't know what java client implementations exists, but looks like at least there is one to send bitcoins.
so is either bitcoinj or one of the outdated java versions .
i will bet some of this webpages that steals your mtgox account
may be using a java exploit.
http://techcrunch.com/2013/04/11/mt-gox-cross-site-scripting-attack-wipes-out-bitcoin-accounts/
i say cut them out and maybe send a message to the bitcoinj project to fix it.
Yea, I was just coming back to mention that those release notes were from 7 years ago lol 
It'd help to know exactly how the signatures are invalid, by the way.
Some of those transactions look like they might originate with a bitcoinj based client (change address is often re-used), but the bouncy castle release notes quoted are from an ancient release. bitcoinj uses version 1.42 and that was a release note for 1.31. I don't think we ever used such an old release.
It's certainly possible there are more bugs in Bouncy Castle though.
It might be worth crossing the address list with the b.i tags list. If only one or two of the addresses are tagged, that could be the break needed.
Alternatively, if it's only 10,000 transactions out of 1.4 million, maybe we can just break them and see who complains
It's certainly possible there are more bugs in Bouncy Castle though.
It might be worth crossing the address list with the b.i tags list. If only one or two of the addresses are tagged, that could be the break needed.
Alternatively, if it's only 10,000 transactions out of 1.4 million, maybe we can just break them and see who complains
Jump to: