Here is another example of a DER signature that is being rejected: 3044022069c288dd4f1995d6f95c6338842dd55934b7ac78c3bae65950ec64e7477cd5c902203fb73d7c329ec4f3da2f403eddc635215673cb13487f0e7e803969488678565001
There are no leading zeroes in this one - so what exactly is wrong with it? |
|
|
|
Whose doing the coding?
https://github.com/ciyam/ciyam/commits/masterFYI - last commit was on new year's day (and I tend to push commits at least once or twice per week). How about you actually try making some valid points rather than trying (and failing miserably with) personal insults? |
|
|
|
Nielsen's Law of Internet bandwidth states that:
a high-end user's connection speed grows by 50% per year
Why is it that when people quote stuff they only quote the bit that serves their own point?  |
|
|
|
@CIYAM what is your opinion of the merits of side chains to solve the 10 minutes problem, and are side chains fundamentally different from the CIYAM project?
I think side chains could be very useful - I think we need to wait a while until we have something to play with before making judgements about that. In regards to the CIYAM project I'm going to offer no comment at this stage other than to say it won't be a "coin". |
|
|
|
You are arguing with a paid troll (NotLambChop)
Don't expect to come out on the winning side of the argument (or have the last word for that matter)
Yup - I am not trying to "win an argument" or help the paid trolls - if this topic devolves much further I'll just lock it. |
|
|
|
Nope, not at all. I'm merely pointing out that you are talking rubbish when you say you are not taking sides. you clearly have.
Oh - so what "side" am I on (strange that you know but I don't)? |
|
|
|
Oh ok. So nothing meant by your opening gambit then:
I see - you have made some sort of important point then? When people are posting as shills and have ad sigs then I think it is entirely reasonable to call them out as being "paid shills" (I am not arguing that they are being paid by anyone other than the ad sig campaign owners). Also Mike Hearn is on record as trying to take control of Bitcoin (so no words were put into his mouth by me). Perhaps you think that I am trying to imply that Mike Hearn is paying all the shills (re-reading my OP I can see why you might think that)? That was not actually what I meant so sorry if I created some confusion with the OP. |
|
|
|
Who's side are you on again?  I don't "take sides" but just try and work out what makes sense or doesn't. If you are able to replace a tx with another (that has a higher fee) then actually you will be able to much more easily cheat (so I don't think merchants will appreciate anything that helps to make that possible). If the merchant is able to pay the fee to lock in the tx then that might work but I still think you have edge cases (such as the fee not being enough to stop the tx from being dropped from the mempool before it is confirmed). As there is simply *no way* to know for sure that your tx won't get dropped from the mempool (apart from perhaps paying ridiculously high fees) then there is no solution to this problem. No such problem exists with existing payment systems so Bitcoin does not really shine in this particular area. |
|
|
|
subchains. means every 30 seconds tx's are locked into blocks and these are then picked up in the order they are made to then form the normal bitcoin blocks. that way if your tx is in the weak block you know its ready to be added, thus helping confidence that it not only will hit a block soon. but also because its in a weak block within 30 seconds.. someone cant then double spend the origin funds as the weak block will ignore those attempts..
I think you should change your terminology as the txs are not "locked into blocks" but "locked into weak blocks" (there is a very big difference). If a miner doesn't care to participate then such "weak blocks" would not be included in a new block so their "safety" is not the same as "real blocks". |
|
|
|
i personally liked the idea of subchains(weakblocks) combined with upping the block limit. that way every ~30seconds
I read about it but am not yet convinced although clearly having some "proof of work" is better than none at all. Overall I think that Bitcoin's biggest problem is that because of the issues that txs may never get confirmed means that it is just not suitable for small things. If the Lightning Network or other things are able to solve this then I'll happily change my opinion but for now I would certainly not recommend any vendor to accept a zero confirmation Bitcoin tx. It isn't like a VISA tx nor a cash one really - so vendors will need to actually understand the problem of zero confirmations (which I think is harder than buying a machine that checks whether or not a fiat note is counterfeit). |
|
|
|
atleast for now, if bitcoin blocked standard usage and went remittance only, for now we could allow for 2% of total remittance.. but it would need to grow.
For sure Bitcoin doesn't scale currently (no-one is arguing that) - the question is about "how to scale it" and just upping the block size is not an intelligent way to do that (which is why the core devs are not proposing to just do that). Those that support BIP101 are not actually even interested in scaling Bitcoin - they just want to take over the project (that much is clear). |
|
|
|
So even with coffee out of the equation, the block size problem remains on the table.
So let's discuss the block size problem. Currently the Bitcoin network can only support around 7 TPS (transactions per second) but you need to realise for a start that it is not "actually 7 txs per second" as a new block only gets created on average every 10 minutes (so a merchant can't expect a payment confirmation in seconds). So no matter how much bigger you make the blocks you don't solve the 10 minutes problem (so the X txs per second are actually not *real* txs per second and never will be). The very design of Bitcoin stops it from being like VISA and this is the point that I have been trying to make. |
|
|
|
sending $5000 from australia to china:
= 23263.52 via western union the recipient will get
= 21115.08 via localbitcoins, the recipient will get
I have never used localbitcoins so I'm not really sure exactly what you are trying to prove. If I send AUD to China from Australia via BTC I would have bought the BTC using an Australian exchange and I would sell the BTC using a Chinese exchange. The localbitcoins would not be involved at all (you can check every post I've ever made and you'll find no reference to localbitcoins as I've never used it once). |
|
|
|
well yea,, lucky once.. when BTC rose.. but thats not an every day event. bitcoin can drop and be stagnant for months too
Okay - I do agree that I was "lucky" at that stage (it wasn't just the one tx but that isn't important). One should not be relying upon luck when moving money around, however, even today if I was wanting to move say 5K AUD to China Bitcoin would most likely be cheaper than a TT (and for huge amounts the savings would be greater). My point is that I have actually used Bitcoin to do remittance and found it cheaper and faster than the banking methods. Why you hate on this I don't really get (I am not trying to sell anything to anyone). |
|
|
|
Also your argument about INR and AUD is rather pointless (although seemingly of some pride to yourself for apparently having "beaten me"). I have never said that Bitcoin is actually succeeding in remittance (even though it should) so the fact that you can find a pair of currencies that will cost you more to trade when using BTC in between is hardly surprising (or even interesting). |
|
|
|
still not the "virtually free /low fee and instant transactions" that many people in bitcoin spout out it as being
My guess is that you are referring to me (and you still haven't linked to where I said "instant transactions"). You are forgetting the use case of just wanting to move "your own money" from A to B (perhaps not the most common case but certainly a percentage of the remittance transactions). I have done this to move AUD to CNY and actually "profited" out of the exchanges (simply because the price of BTC rose way more than the fees during the turnaround time). To move AUD funds via TT (which is the cheapest non-Bitcoin way to do it) costs at a minimum 30 AUD. It of course depends upon what rates and fees you will incur from the Bitcoin exchanges you decide to use but from personal experience I would recommend the usage of Bitcoin for remittance (it never cost me as much as 30 AUD). |
|
|
|
i personally do not accept zero confirms.. which is where i disagree with you on your other posts/topics about the whole 'send instantly to other countries' has been said by you
I don't believe that I have said "instantly" so unless you are going to provide proof that I did I would appreciate it if you didn't put words into my mouth (I'm not putting words into your mouth). In any case the topic is about whether Bitcoin is really suited to competing with VISA (or the like) and therefore whether increasing the block size is an urgent matter or not so can we just stick to that rather than going down the path of "ad hominems", "appeals to authority" or the likes. |
|
|
|
i will actually bother to watch all andrea's videos again, just for the sake of showing you. as you seem to think people lie, unless they are kissing your ass
I didn't accuse you of lying but you are constantly telling me that "I need to provide proof" to back up my statements so I would think you would apply the same standard to yourself. I'm happy to just assume that Andreas has said that (he isn't a technical expert so that would be understandable) but I would be surprised if Gavin has said that. And in either case "appeals to authority" aren't really very convincing are they (especially when we are talking about something that is decentralised)? |
|
|
|
This is the code I've written for creating Bitcoin signatures: https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L513 (the code was originally from Bitcoin itself and is using OpenSSL). It had been working fine (and I also added code to ensure low S values) but now whilst I am trying to test a CLTV tx I am always getting the following error when attempting to send a transaction: error: {"code":-26,"message":"16: mandatory-script-verify-flag-failed (Non-canonical DER signature)"}
This is a sample DER encoded signature: 3045022100da3114f49f3135fa0e3723a2c05ec304f4d16ce3e3f11920e7caa296dd53a9e202206870c44c3681bb9339c1233895a86c6b2861e3d6e6fa562601accae47fc445b201
I do see in the above that there is 00 after the 21 length and am wondering if the zero padding is the problem (the comments I read in the latest Bitcoin code seem to indicate that leading zeroes should not be there unless the value is negative - hmm... but isn't that number negative?). If so what should I change in my code to make sure that the DER signature is being canonically constructed (i.e. is it even possible to be done correctly using OpenSSL or do I need to write code to get rid of the leading zeros myself)? |
|
|
|
Well - I've tried doing this with regtest but unfortunately there seems to be a problem. Raw tx is as follows: 010000000194fb5e28b96182167b73934863fdc6cc23502f2574fdca8230b187fcc768171400000000cb4830450221008854a06bb9fd2fc81e9fe01666481e0fc297
d790e34ed9e801895c1ec101f67b02203692fc017ee22da4259260a71c87e89d15d6b0450f2b531859fc99c748b1aad6012102681362f33ab4c48884c5f7f5aaf501
1d53f0584cf0b257c6c3aff8b0b08241b34c5e76a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a9145e6199a3c0ad
658480247a0f30e314aee23db1eb88ac6701ffb17576a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac68000000000100f2052a010000001976a9145e61
99a3c0ad658480247a0f30e314aee23db1eb88acff000000
and decoded: {
"txid" : "f6ed82fd7f704bd06c93b9504217ea82209d458595e53f702ad3eb30b528109a",
"version" : 1,
"locktime" : 255,
"vin" : [
{
"txid" : "141768c7fc87b13082cafd74252f5023ccc6fd634893737b168261b9285efb94",
"vout" : 0,
"scriptSig" : {
"asm" : "30450221008854a06bb9fd2fc81e9fe01666481e0fc297d790e34ed9e801895c1ec101f67b02203692fc017ee22da4259260a71c87e
89d15d6b0450f2b531859fc99c748b1aad601 02681362f33ab4c48884c5f7f5aaf5011d53f0584cf0b257c6c3aff8b0b08241b3 76a820c775e7b757ede630cd0aa
1113bd102661ab38829ca52a6422ab782862f26864687637576a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac6701ffb17576a9145e6199a3c0ad65848
0247a0f30e314aee23db1eb88ac68",
"hex" : "4830450221008854a06bb9fd2fc81e9fe01666481e0fc297d790e34ed9e801895c1ec101f67b02203692fc017ee22da4259260a71c8
7e89d15d6b0450f2b531859fc99c748b1aad6012102681362f33ab4c48884c5f7f5aaf5011d53f0584cf0b257c6c3aff8b0b08241b34c5e76a820c775e7b757ede63
0cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac6701ffb17576a9145e6199a3c0a
d658480247a0f30e314aee23db1eb88ac68"
},
"sequence" : 0
}
],
"vout" : [
{
"value" : 50.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 5e6199a3c0ad658480247a0f30e314aee23db1eb OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mp7zjTrEszZezRBM1cUmTvaK2zf3MuDAHt"
]
}
}
]
}
I can even issue a "signrawtransaction" and I get this: {
"hex" : "010000000194fb5e28b96182167b73934863fdc6cc23502f2574fdca8230b187fcc7681714000000004948304502210089efd7a1beef7bc3eebde1c
874e0f9092419b2e06b6e0643113d82e532b3e22402207f1350abc802da40a274dfb25969819225c9f61ed2852e4106616a6df3dd17fa01000000000100f2052a010
000001976a9145e6199a3c0ad658480247a0f30e314aee23db1eb88acff000000",
"complete" : true
}
which all looks fine - but when I attempt to send it I get this: error: {"code":-26,"message":"16: mandatory-script-verify-flag-failed (Non-canonical DER signature)"}
 |
|
|
|
|
Show Posts
