OP_CHECKSIG - Bitcoin Wiki

scriptPubKey of type "pubkey" doesn't reference address in getrawtransaction

Hello,
I'm currently working on an application that utilizes calls to the bitcoin-rpc service (via bitcoin-core). I noticed that sometimes there are transactions that when you call decoderawtransaction you will receive a list of VOUTs that have a value greater than 0 (meaning not nulldata) yet don't reference the destination address.

In particular, i'm talking about a VOUT like this:
{
"value": 0.00010000,
"n": 63,
"scriptPubKey": {
"asm": "0293ea48d8841af7a419a24d9da11c34b39127ef041f847651bae6ab14dcd1f6b4 OP_CHECKSIG",
"hex": "210293ea48d8841af7a419a24d9da11c34b39127ef041f847651bae6ab14dcd1f6b4ac",
"type": "pubkey"
}
},


-- Why does this not have an address associated with the corresponding call to decoderawtransaction? Any insight or help would be much appreciated.
submitted by bonsaitree33 to Bitcoin [link] [comments]

Technical: The `SIGHASH_NOINPUT` Debate! Chaperones and output tagging and signature replay oh my!

Bitcoin price isn't moving oh no!!! You know WHAT ELSE isn't moving?? SIGHASH_NOINPUT that's what!!!
Now as you should already know, Decker-Russell-Osuntokun ("eltoo") just ain't possible without SIGHASH_NOINPUT of some kind or other. And Decker-Russell-Osuntokun removes the toxic waste problem (i.e. old backups of your Poon-Dryja LN channels are actively dangerous and could lose your funds if you recover from them, or worse, your most hated enemy could acquire copies of your old state and make you lose funds). Decker-Russell-Osuntokun also allows multiparticipant offchain cryptocurrency update systems, without the drawback of a large unilateral close timeout that Decker-Wattenhofer does, making this construction better for use at the channel factory layer.
Now cdecker already wrote a some code implementing SIGHASH_NOINPUT before, which would make it work in current pre-SegWit P2PKH, P2SH, as well as SegWit v0 P2WPKH and P2WSH. He also made and published BIP 118.
But as is usual for Bitcoin Core development, this triggered debate, and thus many counterproposals were made and so on. Suffice it to say that the simple BIP 118 looks like it won't be coming into Bitcoin Core anytime soon (or possibly at all).
First things first: This link contains all that you need to know, but hey, maybe you'll find my take more amusing.
So let's start with the main issue.

Signature Replay Attack

The above is the Signature Replay Attack, and the reason why SIGHASH_NOINPUT has triggered debate as to whether it is safe at all and whether we can add enough stuff to it to ever make it safe.
Now of course you could point to SIGHASH_NONE which is even worse because all it does is say "I am authorizing the spend of this particular coin of this particular value protected by my key" without any further restrictions like which outputs it goes to. But then SIGHASH_NONE is intended to be used to sacrifice your money to the miners, for example if it's a dust attack trying to get you to spend, so you broadcast a SIGHASH_NONE signature and some enterprising miner will go get a bunch of such SIGHASH_NONE signatures and gather up the dust in a transaction that pays to nobody and gets all the funds as fees. And besides; even if we already have something you could do stupid things with, it's not a justification for adding more things you could do stupid things with.
So yes, SIGHASH_NOINPUT makes Bitcoin more powerful. Now, Bitcoin is a strong believer in "Principle of Least Power". So adding more power to Bitcoin via SIGHASH_NOINPUT is a violation of Principle of Least Power, at least to those arguing to add even more limits to SIGHASH_NOINPUT.
I believe nullc is one of those who strongly urges for adding more limits to SIGHASH_NOINPUT, because it distracts him from taking pictures of his autonomous non-human neighbor, a rather handsome gray fox, but also because it could be used as the excuse for the next MtGox, where a large exchange inadvertently pays to SIGHASH_NOINPUT-using addresses and becomes liable/loses track of their funds when signature replay happens.

Output Tagging

Making SIGHASH_NOINPUT safer by not allowing normal addresses use it.
Basically, we have 32 different SegWit versions. The current SegWit addresses are v0, the next version (v1) is likely to be the Schnorr+Taproot+MAST thing.
What output tagging proposes is to limit SegWit version ranges from 0->15 in the bech32 address scheme (instead of 0->31 it currently has). Versions 16 to 31 are then not valid bech32 SegWit addresses and exchanges shouldn't pay to it.
Then, we allow the use of SIGHASH_NOINPUT only for version 16. Version 16 might very well be Schnorr+Taproot+MAST, with a side serving of SIGHASH_NOINPUT.
This is basically output tagging. SIGHASH_NOINPUT can only be used if the output is tagged (by paying to version 16 SegWit) to allow it, and addresses do not allow outputs to be tagged as such, removing the potential liability of large custodial services like exchanges.
Now, Decker-Russell-Osuntokun channels have two options:
The tradeoffs in this case are:
The latter tradeoff is probably what would be taken (because we're willing to pay for privacy) if Bitcoin Core decides in favor of tagged outputs.
Another issue here is --- oops, P2SH-Segwit wrapped addresses. P2SH can be used to wrap any SegWit payment script, including payments to any SegWit version, including v16. So now you can sneak in a SIGHASH_NOINPUT-enabled SegWit v16 inside an ordinary P2SH that wraps a SegWit payment. One easy way to close this is just to disallow P2SH-SegWit from being valid if it's spending to SegWit version >= 16.

Chaperone Signatures

Closing the Signature Replay Attack by adding a chaperone.
Now we can observe that the Signature Replay Attack is possible because only one signature is needed, and that signature allows any coin of appropriate value to be spent.
Adding a chaperone signature simply means requiring that the SCRIPT involved have at least two OP_CHECKSIG operations. If one signature is SIGHASH_NOINPUT, then at least one other signature (the chaperone) validated by the SCRIPT should be SIGHASH_ALL.
This is not so onerous for Decker-Russell-Osuntokun. Both sides can use a MuSig of their keys, to be used for the SIGHASH_NOINPUT signature (so requires both of them to agree on a particular update), then use a shared ECDH key, to be used for the SIGHASH_ALL signature (allows either of them to publish the unilateral close once the update has been agreed upon).
Of course, the simplest thing to do would be for a BOLT spec to say "just use this spec-defined private key k so we can sidestep the Chaperone Signatures thing". That removes the need to coordinate to define a shared ECDH key during channel establishment: just use the spec-indicated key, which is shared to all LN implementations.
But now look at what we've done! We've subverted the supposed solution of Chaperone Signatures, making them effectively not there, because it's just much easier for everyone to use a standard private key for the chaperone signature than to derive a separate new keypair for the Chaperone.
So chaperone signatures aren't much better than just doing SIGHASH_NOINPUT by itself, and you might as well just use SIGHASH_NOINPUT without adding chaperones.
I believe ajtowns is the primary proponent of this proposal.

Toys for the Big Boys

The Signature Replay Attack is Not A Problem (TM).
This position is most strongly held by RustyReddit I believe (he's the Rusty Russell in the Decker-Russell-Osuntokun). As I understand it, he is more willing to not see SIGHASH_NOINPUT enabled, than to have it enabled but with restrictions like Output Tagging or Chaperone Signatures.
Basically, the idea is: don't use SIGHASH_NOINPUT for normal wallets, in much the same way you don't use SIGHASH_NONE for normal wallets. If you want to do address reuse, don't use wallet software made by luke-jr that specifically screws with your ability to do address reuse.
SIGHASH_NOINPUT is a flag for use by responsible, mutually-consenting adults who want to settle down some satoshis and form a channel together. It is not something that immature youngsters should be playing around with, not until they find a channel counterparty that will treat this responsibility properly. And if those immature youngsters playing with their SIGHASH_NOINPUT flags get into trouble and, you know, lose their funds (as fooling around with SIGHASH_NOINPUT is wont to do), well, they need counseling and advice ("not your keys not your coins", "hodl", "SIGHASH_NOINPUT is not a toy, but something special, reserved for those willing to take on the responsibility of making channels according to the words of Decker-Russell-Osuntokun"...).

Conclusion

Dunno yet. It's still being debated! So yeah. SIGHASH_NOINPUT isn't moving, just like Bitcoin's price!!! YAAAAAAAAAAAAAAAAAAA.
submitted by almkglor to Bitcoin [link] [comments]

Transcript of the community Q&A with Steve Shadders and Daniel Connolly of the Bitcoin SV development team. We talk about the path to big blocks, new opcodes, selfish mining, malleability, and why November will lead to a divergence in consensus rules. (Cont in comments)

We've gone through the painstaking process of transcribing the linked interview with Steve Shadders and Daniell Connolly of the Bitcoin SV team. There is an amazing amount of information in this interview that we feel is important for businesses and miners to hear, so we believe it was important to get this is a written form. To avoid any bias, the transcript is taken almost word for word from the video, with just a few changes made for easier reading. If you see any corrections that need to be made, please let us know.
Each question is in bold, and each question and response is timestamped accordingly. You can follow along with the video here:
https://youtu.be/tPImTXFb_U8

BEGIN TRANSCRIPT:

Connor: 02:19.68,0:02:45.10
Alright so thank You Daniel and Steve for joining us. We're joined by Steve Shadders and Daniel Connolly from nChain and also the lead developers of the Satoshi’s Vision client. So Daniel and Steve do you guys just want to introduce yourselves before we kind of get started here - who are you guys and how did you get started?
Steve: 0,0:02:38.83,0:03:30.61
So I'm Steve Shadders and at nChain I am the director of solutions in engineering and specifically for Bitcoin SV I am the technical director of the project which means that I'm a bit less hands-on than Daniel but I handle a lot of the liaison with the miners - that's the conditional project.
Daniel:
Hi I’m Daniel I’m the lead developer for Bitcoin SV. As the team's grown that means that I do less actual coding myself but more organizing the team and organizing what we’re working on.
Connor 03:23.07,0:04:15.98
Great so we took some questions - we asked on Reddit to have people come and post their questions. We tried to take as many of those as we could and eliminate some of the duplicates, so we're gonna kind of go through each question one by one. We added some questions of our own in and we'll try and get through most of these if we can. So I think we just wanted to start out and ask, you know, Bitcoin Cash is a little bit over a year old now. Bitcoin itself is ten years old but in the past a little over a year now what has the process been like for you guys working with the multiple development teams and, you know, why is it important that the Satoshi’s vision client exists today?
Steve: 0:04:17.66,0:06:03.46
I mean yes well we’ve been in touch with the developer teams for quite some time - I think a bi-weekly meeting of Bitcoin Cash developers across all implementations started around November last year. I myself joined those in January or February of this year and Daniel a few months later. So we communicate with all of those teams and I think, you know, it's not been without its challenges. It's well known that there's a lot of disagreements around it, but some what I do look forward to in the near future is a day when the consensus issues themselves are all rather settled, and if we get to that point then there's not going to be much reason for the different developer teams to disagree on stuff. They might disagree on non-consensus related stuff but that's not the end of the world because, you know, Bitcoin Unlimited is free to go and implement whatever they want in the back end of a Bitcoin Unlimited and Bitcoin SV is free to do whatever they want in the backend, and if they interoperate on a non-consensus level great. If they don't not such a big problem there will obviously be bridges between the two, so, yeah I think going forward the complications of having so many personalities with wildly different ideas are going to get less and less.
Cory: 0:06:00.59,0:06:19.59
I guess moving forward now another question about the testnet - a lot of people on Reddit have been asking what the testing process for Bitcoin SV has been like, and if you guys plan on releasing any of those results from the testing?
Daniel: 0:06:19.59,0:07:55.55
Sure yeah so our release will be concentrated on the stability, right, with the first release of Bitcoin SV and that involved doing a large amount of additional testing particularly not so much at the unit test level but at the more system test so setting up test networks, performing tests, and making sure that the software behaved as we expected, right. Confirming the changes we made, making sure that there aren’t any other side effects. Because of, you know, it was quite a rush to release the first version so we've got our test results documented, but not in a way that we can really release them. We're thinking about doing that but we’re not there yet.
Steve: 0:07:50.25,0:09:50.87
Just to tidy that up - we've spent a lot of our time developing really robust test processes and the reporting is something that we can read on our internal systems easily, but we need to tidy that up to give it out for public release. The priority for us was making sure that the software was safe to use. We've established a test framework that involves a progression of code changes through multiple test environments - I think it's five different test environments before it gets the QA stamp of approval - and as for the question about the testnet, yeah, we've got four of them. We've got Testnet One and Testnet Two. A slightly different numbering scheme to the testnet three that everyone's probably used to – that’s just how we reference them internally. They're [1 and 2] both forks of Testnet Three. [Testnet] One we used for activation testing, so we would test things before and after activation - that one’s set to reset every couple of days. The other one [Testnet Two] was set to post activation so that we can test all of the consensus changes. The third one was a performance test network which I think most people have probably have heard us refer to before as Gigablock Testnet. I get my tongue tied every time I try to say that word so I've started calling it the Performance test network and I think we're planning on having two of those: one that we can just do our own stuff with and experiment without having to worry about external unknown factors going on and having other people joining it and doing stuff that we don't know about that affects our ability to baseline performance tests, but the other one (which I think might still be a work in progress so Daniel might be able to answer that one) is one of them where basically everyone will be able to join and they can try and mess stuff up as bad as they want.
Daniel: 0:09:45.02,0:10:20.93
Yeah, so we so we recently shared the details of Testnet One and Two with the with the other BCH developer groups. The Gigablock test network we've shared up with one group so far but yeah we're building it as Steve pointed out to be publicly accessible.
Connor: 0:10:18.88,0:10:44.00
I think that was my next question I saw that you posted on Twitter about the revived Gigablock testnet initiative and so it looked like blocks bigger than 32 megabytes were being mined and propagated there, but maybe the block explorers themselves were coming down - what does that revived Gigablock test initiative look like?
Daniel: 0:10:41.62,0:11:58.34
That's what did the Gigablock test network is. So the Gigablock test network was first set up by Bitcoin Unlimited with nChain’s help and they did some great work on that, and we wanted to revive it. So we wanted to bring it back and do some large-scale testing on it. It's a flexible network - at one point we had we had eight different large nodes spread across the globe, sort of mirroring the old one. Right now we scaled back because we're not using it at the moment so they'll notice I think three. We have produced some large blocks there and it's helped us a lot in our research and into the scaling capabilities of Bitcoin SV, so it's guided the work that the team’s been doing for the last month or two on the improvements that we need for scalability.
Steve: 0:11:56.48,0:13:34.25
I think that's actually a good point to kind of frame where our priorities have been in kind of two separate stages. I think, as Daniel mentioned before, because of the time constraints we kept the change set for the October 15 release as minimal as possible - it was just the consensus changes. We didn't do any work on performance at all and we put all our focus and energy into establishing the QA process and making sure that that change was safe and that was a good process for us to go through. It highlighted what we were missing in our team – we got our recruiters very busy recruiting of a Test Manager and more QA people. The second stage after that is performance related work which, as Daniel mentioned, the results of our performance testing fed into what tasks we were gonna start working on for the performance related stuff. Now that work is still in progress - some of the items that we identified the code is done and that's going through the QA process but it’s not quite there yet. That's basically the two-stage process that we've been through so far. We have a roadmap that goes further into the future that outlines more stuff, but primarily it’s been QA first, performance second. The performance enhancements are close and on the horizon but some of that work should be ongoing for quite some time.
Daniel: 0:13:37.49,0:14:35.14
Some of the changes we need for the performance are really quite large and really get down into the base level view of the software. There's kind of two groups of them mainly. One that are internal to the software – to Bitcoin SV itself - improving the way it works inside. And then there's other ones that interface it with the outside world. One of those in particular we're working closely with another group to make a compatible change - it's not consensus changing or anything like that - but having the same interface on multiple different implementations will be very helpful right, so we're working closely with them to make improvements for scalability.
Connor: 0:14:32.60,0:15:26.45
Obviously for Bitcoin SV one of the main things that you guys wanted to do that that some of the other developer groups weren't willing to do right now is to increase the maximum default block size to 128 megabytes. I kind of wanted to pick your brains a little bit about - a lot of the objection to either removing the box size entirely or increasing it on a larger scale is this idea of like the infinite block attack right and that kind of came through in a lot of the questions. What are your thoughts on the “infinite block attack” and is it is it something that that really exists, is it something that miners themselves should be more proactive on preventing, or I guess what are your thoughts on that attack that everyone says will happen if you uncap the block size?
Steve: 0:15:23.45,0:18:28.56
I'm often quoted on Twitter and Reddit - I've said before the infinite block attack is bullshit. Now, that's a statement that I suppose is easy to take out of context, but I think the 128 MB limit is something where there’s probably two schools of thought about. There are some people who think that you shouldn't increase the limit to 128 MB until the software can handle it, and there are others who think that it's fine to do it now so that the limit is increased when the software can handle it and you don’t run into the limit when this when the software improves and can handle it. Obviously we’re from the latter school of thought. As I said before we've got a bunch of performance increases, performance enhancements, in the pipeline. If we wait till May to increase the block size limit to 128 MB then those performance enhancements will go in, but we won't be able to actually demonstrate it on mainnet. As for the infinitive block attack itself, I mean there are a number of mitigations that you can put in place. I mean firstly, you know, going down to a bit of the tech detail - when you send a block message or send any peer to peer message there's a header which has the size of the message. If someone says they're sending you a 30MB message and you're receiving it and it gets to 33MB then obviously you know something's wrong so you can drop the connection. If someone sends you a message that's 129 MB and you know the block size limit is 128 you know it’s kind of pointless to download that message. So I mean these are just some of the mitigations that you can put in place. When I say the attack is bullshit, I mean I mean it is bullshit from the sense that it's really quite trivial to prevent it from happening. I think there is a bit of a school of thought in the Bitcoin world that if it's not in the software right now then it kind of doesn't exist. I disagree with that, because there are small changes that can be made to work around problems like this. One other aspect of the infinite block attack, and let’s not call it the infinite block attack, let's just call it the large block attack - it takes a lot of time to validate that we gotten around by having parallel pipelines for blocks to come in, so you've got a block that's coming in it's got a unknown stuck on it for two hours or whatever downloading and validating it. At some point another block is going to get mined b someone else and as long as those two blocks aren't stuck in a serial pipeline then you know the problem kind of goes away.
Cory: 0:18:26.55,0:18:48.27
Are there any concerns with the propagation of those larger blocks? Because there's a lot of questions around you know what the practical size of scaling right now Bitcoin SV could do and the concerns around propagating those blocks across the whole network.
Steve 0:18:45.84,0:21:37.73
Yes, there have been concerns raised about it. I think what people forget is that compact blocks and xThin exist, so if a 32MB block is not send 32MB of data in most cases, almost all cases. The concern here that I think I do find legitimate is the Great Firewall of China. Very early on in Bitcoin SV we started talking with miners on the other side of the firewall and that was one of their primary concerns. We had anecdotal reports of people who were having trouble getting a stable connection any faster than 200 kilobits per second and even with compact blocks you still need to get the transactions across the firewall. So we've done a lot of research into that - we tested our own links across the firewall, rather CoinGeeks links across the firewall as they’ve given us access to some of their servers so that we can play around, and we were able to get sustained rates of 50 to 90 megabits per second which pushes that problem quite a long way down the road into the future. I don't know the maths off the top of my head, but the size of the blocks that can sustain is pretty large. So we're looking at a couple of options - it may well be the chattiness of the peer-to-peer protocol causes some of these issues with the Great Firewall, so we have someone building a bridge concept/tool where you basically just have one kind of TX vacuum on either side of the firewall that collects them all up and sends them off every one or two seconds as a single big chunk to eliminate some of that chattiness. The other is we're looking at building a multiplexer that will sit and send stuff up to the peer-to-peer network on one side and send it over splitters, to send it over multiple links, reassemble it on the other side so we can sort of transition the great Firewall without too much trouble, but I mean getting back to the core of your question - yes there is a theoretical limit to block size propagation time and that's kind of where Moore's Law comes in. Putting faster links and you kick that can further down the road and you just keep on putting in faster links. I don't think 128 main blocks are going to be an issue though with the speed of the internet that we have nowadays.
Connor: 0:21:34.99,0:22:17.84
One of the other changes that you guys are introducing is increasing the max script size so I think right now it’s going from 201 to 500 [opcodes]. So I guess a few of the questions we got was I guess #1 like why not uncap it entirely - I think you guys said you ran into some concerns while testing that - and then #2 also specifically we had a question about how certain are you that there are no remaining n squared bugs or vulnerabilities left in script execution?
Steve: 0:22:15.50,0:25:36.79
It's interesting the decision - we were initially planning on removing that cap altogether and the next cap that comes into play after that (next effective cap is a 10,000 byte limit on the size of the script). We took a more conservative route and decided to wind that back to 500 - it's interesting that we got some criticism for that when the primary criticism I think that was leveled against us was it’s dangerous to increase that limit to unlimited. We did that because we’re being conservative. We did some research into these log n squared bugs, sorry – attacks, that people have referred to. We identified a few of them and we had a hard think about it and thought - look if we can find this many in a short time we can fix them all (the whack-a-mole approach) but it does suggest that there may well be more unknown ones. So we thought about putting, you know, taking the whack-a-mole approach, but that doesn't really give us any certainty. We will fix all of those individually but a more global approach is to make sure that if anyone does discover one of these scripts it doesn't bring the node to a screaming halt, so the problem here is because the Bitcoin node is essentially single-threaded, if you get one of these scripts that locks up the script engine for a long time everything that's behind it in the queue has to stop and wait. So what we wanted to do, and this is something we've got an engineer actively working on right now, is once that script validation goad path is properly paralyzed (parts of it already are), then we’ll basically assign a few threads for well-known transaction templates, and a few threads for any any type of script. So if you get a few scripts that are nasty and lock up a thread for a while that's not going to stop the node from working because you've got these other kind of lanes of the highway that are exclusively reserved for well-known script templates and they'll just keep on passing through. Once you've got that in place, and I think we're in a much better position to get rid of that limit entirely because the worst that's going to happen is your non-standard script pipelines get clogged up but everything else will keep keep ticking along - there are other mitigations for this as well I mean I know you could always put a time limit on script execution if they wanted to, and that would be something that would be up to individual miners. Bitcoin SV's job I think is to provide the tools for the miners and the miners can then choose, you know, how to make use of them - if they want to set time limits on script execution then that's a choice for them.
Daniel: 0:25:34.82,0:26:15.85
Yeah, I'd like to point out that a node here, when it receives a transaction through the peer to peer network, it doesn't have to accept that transaction, you can reject it. If it looks suspicious to the node it can just say you know we're not going to deal with that, or if it takes more than five minutes to execute, or more than a minute even, it can just abort and discard that transaction, right. The only time we can’t do that is when it's in a block already, but then it could decide to reject the block as well. It's all possibilities there could be in the software.
Steve: 0:26:13.08,0:26:20.64
Yeah, and if it's in a block already it means someone else was able to validate it so…
Cory: 0,0:26:21.21,0:26:43.60
There’s a lot of discussions about the re-enabled opcodes coming – OP_MUL, OP_INVERT, OP_LSHIFT, and OP_RSHIFT up invert op l shift and op r shift you maybe explain the significance of those op codes being re-enabled?
Steve: 0:26:42.01,0:28:17.01
Well I mean one of one of the most significant things is other than two, which are minor variants of DUP and MUL, they represent almost the complete set of original op codes. I think that's not necessarily a technical issue, but it's an important milestone. MUL is one that's that I've heard some interesting comments about. People ask me why are you putting OP_MUL back in if you're planning on changing them to big number operations instead of the 32-bit limit that they're currently imposed upon. The simple answer to that question is that we currently have all of the other arithmetic operations except for OP_MUL. We’ve got add divide, subtract, modulo – it’s odd to have a script system that's got all the mathematical primitives except for multiplication. The other answer to that question is that they're useful - we've talked about a Rabin signature solution that basically replicates the function of DATASIGVERIFY. That's just one example of a use case for this - most cryptographic primitive operations require mathematical operations and bit shifts are useful for a whole ton of things. So it's really just about completing that work and completing the script engine, or rather not completing it, but putting it back the way that it was it was meant to be.
Connor 0:28:20.42,0:29:22.62
Big Num vs 32 Bit. I've seen Daniel - I think I saw you answer this on Reddit a little while ago, but the new op codes using logical shifts and Satoshi’s version use arithmetic shifts - the general question that I think a lot of people keep bringing up is, maybe in a rhetorical way but they say why not restore it back to the way Satoshi had it exactly - what are the benefits of changing it now to operate a little bit differently?
Daniel: 0:29:18.75,0:31:12.15
Yeah there's two parts there - the big number one and the L shift being a logical shift instead of arithmetic. so when we re-enabled these opcodes we've looked at them carefully and have adjusted them slightly as we did in the past with OP_SPLIT. So the new LSHIFT and RSHIFT are bitwise operators. They can be used to implement arithmetic based shifts - I think I've posted a short script that did that, but we can't do it the other way around, right. You couldn't use an arithmetic shift operator to implement a bitwise one. It's because of the ordering of the bytes in the arithmetic values, so the values that represent numbers. The little endian which means they're swapped around to what many other systems - what I've considered normal - or big-endian. And if you start shifting that properly as a number then then shifting sequence in the bytes is a bit strange, so it couldn't go the other way around - you couldn't implement bitwise shift with arithmetic, so we chose to make them bitwise operators - that's what we proposed.
Steve: 0:31:10.57,0:31:51.51
That was essentially a decision that was actually made in May, or rather a consequence of decisions that were made in May. So in May we reintroduced OP_AND, OP_OR, and OP_XOR, and that was also another decision to replace three different string operators with OP_SPLIT was also made. So that was not a decision that we've made unilaterally, it was a decision that was made collectively with all of the BCH developers - well not all of them were actually in all of the meetings, but they were all invited.
Daniel: 0:31:48.24,0:32:23.13
Another example of that is that we originally proposed OP_2DIV and OP_2MUL was it, I think, and this is a single operator that multiplies the value by two, right, but it was pointed out that that can very easily be achieved by just doing multiply by two instead of having a separate operator for it, so we scrapped those, we took them back out, because we wanted to keep the number of operators minimum yeah.
Steve: 0:32:17.59,0:33:47.20
There was an appetite around for keeping the operators minimal. I mean the decision about the idea to replace OP_SUBSTR, OP_LEFT, OP_RIGHT with OP_SPLIT operator actually came from Gavin Andresen. He made a brief appearance in the Telegram workgroups while we were working out what to do with May opcodes and obviously Gavin's word kind of carries a lot of weight and we listen to him. But because we had chosen to implement the May opcodes (the bitwise opcodes) and treat the data as big-endian data streams (well, sorry big-endian not really applicable just plain data strings) it would have been completely inconsistent to implement LSHIFT and RSHIFT as integer operators because then you would have had a set of bitwise operators that operated on two different kinds of data, which would have just been nonsensical and very difficult for anyone to work with, so yeah. I mean it's a bit like P2SH - it wasn't a part of the original Satoshi protocol that once some things are done they're done and you know if you want to want to make forward progress you've got to work within that that framework that exists.
Daniel: 0:33:45.85,0:34:48.97
When we get to the big number ones then it gets really complicated, you know, number implementations because then you can't change the behavior of the existing opcodes, and I don't mean OP_MUL, I mean the other ones that have been there for a while. You can't suddenly make them big number ones without seriously looking at what scripts there might be out there and the impact of that change on those existing scripts, right. The other the other point is you don't know what scripts are out there because of P2SH - there could be scripts that you don't know the content of and you don't know what effect changing the behavior of these operators would mean. The big number thing is tricky, so another option might be, yeah, I don't know what the options for though it needs some serious thought.
Steve: 0:34:43.27,0:35:24.23
That’s something we've reached out to the other implementation teams about - actually really would like their input on the best ways to go about restoring big number operations. It has to be done extremely carefully and I don't know if we'll get there by May next year, or when, but we’re certainly willing to put a lot of resources into it and we're more than happy to work with BU or XT or whoever wants to work with us on getting that done and getting it done safely.
Connor: 0:35:19.30,0:35:57.49
Kind of along this similar vein, you know, Bitcoin Core introduced this concept of standard scripts, right - standard and non-standard scripts. I had pretty interesting conversation with Clemens Ley about use cases for “non-standard scripts” as they're called. I know at least one developer on Bitcoin ABC is very hesitant, or kind of pushed back on him about doing that and so what are your thoughts about non-standard scripts and the entirety of like an IsStandard check?
Steve: 0:35:58.31,0:37:35.73
I’d actually like to repurpose the concept. I think I mentioned before multi-threaded script validation and having some dedicated well-known script templates - when you say the word well-known script template there’s already a check in Bitcoin that kind of tells you if it's well-known or not and that's IsStandard. I'm generally in favor of getting rid of the notion of standard transactions, but it's actually a decision for miners, and it's really more of a behavioral change than it is a technical change. There's a whole bunch of configuration options that miners can set that affect what they do what they consider to be standard and not standard, but the reality is not too many miners are using those configuration options. So I mean standard transactions as a concept is meaningful to an arbitrary degree I suppose, but yeah I would like to make it easier for people to get non-standard scripts into Bitcoin so that they can experiment, and from discussions of I’ve had with CoinGeek they’re quite keen on making their miners accept, you know, at least initially a wider variety of transactions eventually.
Daniel: 0:37:32.85,0:38:07.95
So I think IsStandard will remain important within the implementation itself for efficiency purposes, right - you want to streamline base use case of cash payments through them and prioritizing. That's where it will remain important but on the interfaces from the node to the rest of the network, yeah I could easily see it being removed.
Cory: 0,0:38:06.24,0:38:35.46
*Connor mentioned that there's some people that disagree with Bitcoin SV and what they're doing - a lot of questions around, you know, why November? Why implement these changes in November - they think that maybe the six-month delay might not cause a split. Well, first off what do you think about the ideas of a potential split and I guess what is the urgency for November?
Steve: 0:38:33.30,0:40:42.42
Well in November there's going to be a divergence of consensus rules regardless of whether we implement these new op codes or not. Bitcoin ABC released their spec for the November Hard fork change I think on August 16th or 17th something like that and their client as well and it included CTOR and it included DSV. Now for the miners that commissioned the SV project, CTOR and DSV are controversial changes and once they're in they're in. They can't be reversed - I mean CTOR maybe you could reverse it at a later date, but DSV once someone's put a P2SH transaction into the project or even a non P2SH transaction in the blockchain using that opcode it's irreversible. So it's interesting that some people refer to the Bitcoin SV project as causing a split - we're not proposing to do anything that anyone disagrees with - there might be some contention about changing the opcode limit but what we're doing, I mean Bitcoin ABC already published their spec for May and it is our spec for the new opcodes, so in terms of urgency - should we wait? Well the fact is that we can't - come November you know it's bit like Segwit - once Segwit was in, yes you arguably could get it out by spending everyone's anyone can spend transactions but in reality it's never going to be that easy and it's going to cause a lot of economic disruption, so yeah that's it. We're putting out changes in because it's not gonna make a difference either way in terms of whether there's going to be a divergence of consensus rules - there's going to be a divergence whether whatever our changes are. Our changes are not controversial at all.
Daniel: 0:40:39.79,0:41:03.08
If we didn't include these changes in the November upgrade we'd be pushing ahead with a no-change, right, but the November upgrade is there so we should use it while we can. Adding these non-controversial changes to it.
Connor: 0:41:01.55,0:41:35.61
Can you talk about DATASIGVERIFY? What are your concerns with it? The general concept that's been kind of floated around because of Ryan Charles is the idea that it's a subsidy, right - that it takes a whole megabyte and kind of crunches that down and the computation time stays the same but maybe the cost is lesser - do you kind of share his view on that or what are your concerns with it?
Daniel: 0:41:34.01,0:43:38.41
Can I say one or two things about this – there’s different ways to look at that, right. I'm an engineer - my specialization is software, so the economics of it I hear different opinions. I trust some more than others but I am NOT an economist. I kind of agree with the ones with my limited expertise on that it's a subsidy it looks very much like it to me, but yeah that's not my area. What I can talk about is the software - so adding DSV adds really quite a lot of complexity to the code right, and it's a big change to add that. And what are we going to do - every time someone comes up with an idea we’re going to add a new opcode? How many opcodes are we going to add? I saw reports that Jihan was talking about hundreds of opcodes or something like that and it's like how big is this client going to become - how big is this node - is it going to have to handle every kind of weird opcode that that's out there? The software is just going to get unmanageable and DSV - that was my main consideration at the beginning was the, you know, if you can implement it in script you should do it, because that way it keeps the node software simple, it keeps it stable, and you know it's easier to test that it works properly and correctly. It's almost like adding (?) code from a microprocessor you know why would you do that if you can if you can implement it already in the script that is there.
Steve: 0:43:36.16,0:46:09.71
It’s actually an interesting inconsistency because when we were talking about adding the opcodes in May, the philosophy that seemed to drive the decisions that we were able to form a consensus around was to simplify and keep the opcodes as minimal as possible (ie where you could replicate a function by using a couple of primitive opcodes in combination, that was preferable to adding a new opcode that replaced) OP_SUBSTR is an interesting example - it's a combination of SPLIT, and SWAP and DROP opcodes to achieve it. So at really primitive script level we've got this philosophy of let's keep it minimal and at this sort of (?) philosophy it’s all let's just add a new opcode for every primitive function and Daniel's right - it's a question of opening the floodgates. Where does it end? If we're just going to go down this road, it almost opens up the argument why have a scripting language at all? Why not just add a hard code all of these functions in one at a time? You know, pay to public key hash is a well-known construct (?) and not bother executing a script at all but once we've done that we take away with all of the flexibility for people to innovate, so it's a philosophical difference, I think, but I think it's one where the position of keeping it simple does make sense. All of the primitives are there to do what people need to do. The things that people don't feel like they can't do are because of the limits that exist. If we had no opcode limit at all, if you could make a gigabyte transaction so a gigabyte script, then you can do any kind of crypto that you wanted even with 32-bit integer operations, Once you get rid of the 32-bit limit of course, a lot of those a lot of those scripts come up a lot smaller, so a Rabin signature script shrinks from 100MB to a couple hundred bytes.
Daniel: 0:46:06.77,0:47:36.65
I lost a good six months of my life diving into script, right. Once you start getting into the language and what it can do, it is really pretty impressive how much you can achieve within script. Bitcoin was designed, was released originally, with script. I mean it didn't have to be – it could just be instead of having a transaction with script you could have accounts and you could say trust, you know, so many BTC from this public key to this one - but that's not the way it was done. It was done using script, and script provides so many capabilities if you start exploring it properly. If you start really digging into what it can do, yeah, it's really amazing what you can do with script. I'm really looking forward to seeing some some very interesting applications from that. I mean it was Awemany his zero-conf script was really interesting, right. I mean it relies on DSV which is a problem (and some other things that I don't like about it), but him diving in and using script to solve this problem was really cool, it was really good to see that.
Steve: 0:47:32.78,0:48:16.44
I asked a question to a couple of people in our research team that have been working on the Rabin signature stuff this morning actually and I wasn't sure where they are up to with this, but they're actually working on a proof of concept (which I believe is pretty close to done) which is a Rabin signature script - it will use smaller signatures so that it can fit within the current limits, but it will be, you know, effectively the same algorithm (as DSV) so I can't give you an exact date on when that will happen, but it looks like we'll have a Rabin signature in the blockchain soon (a mini-Rabin signature).
Cory: 0:48:13.61,0:48:57.63
Based on your responses I think I kinda already know the answer to this question, but there's a lot of questions about ending experimentation on Bitcoin. I was gonna kind of turn that into – with the plan that Bitcoin SV is on do you guys see like a potential one final release, you know that there's gonna be no new opcodes ever released (like maybe five years down the road we just solidify the base protocol and move forward with that) or are you guys more on the idea of being open-ended with appropriate testing that we can introduce new opcodes under appropriate testing.
Steve: 0:48:55.80,0:49:47.43
I think you've got a factor in what I said before about the philosophical differences. I think new functionality can be introduced just fine. Having said that - yes there is a place for new opcodes but it's probably a limited place and in my opinion the cryptographic primitive functions for example CHECKSIG uses ECDSA with a specific elliptic curve, hash 256 uses SHA256 - at some point in the future those are going to no longer be as secure as we would like them to be and we'll replace them with different hash functions, verification functions, at some point, but I think that's a long way down the track.
Daniel: 0:49:42.47,0:50:30.3
I'd like to see more data too. I'd like to see evidence that these things are needed, and the way I could imagine that happening is that, you know, that with the full scripting language some solution is implemented and we discover that this is really useful, and over a period of, like, you know measured in years not days, we find a lot of transactions are using this feature, then maybe, you know, maybe we should look at introducing an opcode to optimize it, but optimizing before we even know if it's going to be useful, yeah, that's the wrong approach.
Steve: 0:50:28.19,0:51:45.29
I think that optimization is actually going to become an economic decision for the miners. From the miner’s point of view is if it'll make more sense for them to be able to optimize a particular process - does it reduce costs for them such that they can offer a better service to everyone else? Yeah, so ultimately these decisions are going to be miner’s main decisions, not developer decisions. Developers of course can offer their input - I wouldn't expect every miner to be an expert on script, but as we're already seeing miners are actually starting to employ their own developers. I’m not just talking about us - there are other miners in China that I know have got some really bright people on their staff that question and challenge all of the changes - study them and produce their own reports. We've been lucky with actually being able to talk to some of those people and have some really fascinating technical discussions with them.
submitted by The_BCH_Boys to btc [link] [comments]

Those large Bitcoin Cash transactions are not what you think they are

I've decided to take a look at these large transactions that occurred on Bitcoin Cash yesterday. I have analyzed them to see what they are doing, and it is actually kind of funny. Contrary to popular belief, those transactions are not preparation transactions for the attack presented by _chjj yesterday, and I will explain why below.
For starters, lets look at the large transactions. There are 7 of them: https://bch-bitcore2.trezor.io/tx/ac4849b3b03e44d5fcba8becfc642a8670049b59436d6c7ab89a4d3873d9a3ef, https://bch-bitcore2.trezor.io/tx/1bd4f08ffbeefbb67d82a340dd35259a97c5626368f8a6efa056571b293fae52, https://bch-bitcore2.trezor.io/tx/c0472d267c8d178804eefdddb348f2f7a8a95bf6a4152b952a5fb6bfa09cab2e, https://bch-bitcore2.trezor.io/tx/27cb862d9c4c7eaace8d901e89365f2e843572788b774b14e5675fd9107d6637, https://bch-bitcore2.trezor.io/tx/b87d1dc8c0f3b450f1c1a845a5561ad87d850173b852c6839de6eb04441dfc7f, https://bch-bitcore2.trezor.io/tx/fc3e3bbd49ad6a6e87e7220f380b24ae86e566b1d26d0e40fb5250e54a25dc2a, https://bch-bitcore2.trezor.io/tx/dbd3f7518111d679c1b229af71181c9395e3bf8c1370b6856376f391d25c883e. Each of these transactions has 31243 identical P2SH outputs of 1 satoshi each, and one change output. So at first glance, these look a lot like attack transactions for _chjj's attack. But looking closer, it looks like the first output of each transaction has been spent in https://bch-bitcore2.trezor.io/tx/36a094b53ef46b1ffdfd853079be9f21da4a5f789dd28c9d7c6d84770a7b5c1d. Lets take a closer look at that transaction
36a094b53ef46b1ffdfd853079be9f21da4a5f789dd28c9d7c6d84770a7b5c1d is strangely large for a transaction spending P2SH outputs, it is nearly 70 kB but only spends 7 inputs. This means that those inputs must be massive, almost 10 kB each, which, incidentally, is the size limit for a scriptSig. Unfortunately block explorers based on insight aren't showing us the scriptSig, so this will need to be decoded with a node.
Here is the decoded output (I have cut out a few things because it is too large):
{ "hex": , "txid": "36a094b53ef46b1ffdfd853079be9f21da4a5f789dd28c9d7c6d84770a7b5c1d", "hash": "36a094b53ef46b1ffdfd853079be9f21da4a5f789dd28c9d7c6d84770a7b5c1d", "size": 69651, "version": 2, "locktime": 0, "vin": [ { "txid": "ac4849b3b03e44d5fcba8becfc642a8670049b59436d6c7ab89a4d3873d9a3ef", "vout": 0, "scriptSig": { "asm": "492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 78887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884cab492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e87", "hex":  }, "sequence": 4294967295 }, { "txid": "1bd4f08ffbeefbb67d82a340dd35259a97c5626368f8a6efa056571b293fae52", "vout": 0, "scriptSig": { "asm": "492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e  492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e 788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c89492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e87", "hex":  }, "sequence": 4294967295 }, { "txid": "c0472d267c8d178804eefdddb348f2f7a8a95bf6a4152b952a5fb6bfa09cab2e", "vout": 0, "scriptSig": { "asm": "57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d6172740a57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d617274  57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d6172740a57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d617274 7888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c8f57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d6172740a57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d61727487", "hex":  }, "sequence": 4294967295 }, { "txid": "27cb862d9c4c7eaace8d901e89365f2e843572788b774b14e5675fd9107d6637", "vout": 0, "scriptSig": { "asm": "492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f736869  492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f736869 78887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c8b492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f73686987", "hex":  }, "sequence": 4294967295 }, { "txid": "b87d1dc8c0f3b450f1c1a845a5561ad87d850173b852c6839de6eb04441dfc7f", "vout": 0, "scriptSig": { "asm": "4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b  788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c904920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b87", "hex":  }, "sequence": 4294967295 }, { "txid": "fc3e3bbd49ad6a6e87e7220f380b24ae86e566b1d26d0e40fb5250e54a25dc2a", "vout": 0, "scriptSig": { "asm": "48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d6978  48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d6978 78887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c8b48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d697887", "hex":  }, "sequence": 4294967295 }, { "txid": "dbd3f7518111d679c1b229af71181c9395e3bf8c1370b6856376f391d25c883e", "vout": 0, "scriptSig": { "asm": "5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d65  5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d65 7888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884c935468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d6587", "hex":  }, "sequence": 4294967295 } ], "vout": [ { "value": 0.00000000, "n": 0, "scriptPubKey": { "asm": "OP_DUP OP_HASH160 f6c403dd1f02211d21db137cd219e156ce7e5ca7 OP_EQUALVERIFY OP_CHECKSIG", "hex": "76a914f6c403dd1f02211d21db137cd219e156ce7e5ca788ac", "reqSigs": 1, "type": "pubkeyhash", "addresses": [ "1PVn3ZM5mUW9n9eVXRAedUbpJdAMCG7KXS" ] } } ], "blockhash": "000000000000000005a42e167af40866487ceda82863614c409d67d1239aff19", "confirmations": 174, "time": 1505044920, "blocktime": 1505044920 } 
Well that's interesting. Lets find the redeemScript of the first transaction and decode it:
bitcoin-cli decodescript 78887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878887888788878884cab492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e87 { "asm": "OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY OP_OVER OP_EQUALVERIFY 492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e OP_EQUAL", "type": "nonstandard", "p2sh": "39BLXfKysaXNuGuBrgT7b9WfaiBMw2VMZf" } 
Well that is a very interesting script. So lets explore what this script is doing. OP_OVER means that the top stack item is copied, e.g. x1 x2 -> x1 x2 x1. OP_EQUALVERIFY means that the top two stack items must be equal to each other and they are consumed. There are 55 OP_OVER OP_EQUALVERIFY pairs here, which means that something will need to be repeated 55 times. At the end of the script, we see this byte string and then OP_EQUAL. That means that whatever is being repeated much match this byte string in order for this script to validate. The scriptSig that this redeemScript comes from does exactly that, the byte string at the bottom of the script are repeated a bunch of times. And it looks like all of the 7 scripts do basically the same thing, but with different length byte strings. Now lets see what our byte strings are.
492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e0a492077696c6c206e6f7420636c6f6e6520426974636f696e20666f7220706572736f6e616c206761696e 492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e0a492077696c6c206e6f74207573652061737365727428302920666f7220696e7075742076616c69646174696f6e 57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d6172740a57726974696e6720676962626572697368206571756174696f6e73206f6e206120626c61636b626f61726420646f6573206e6f74206d616b65206d65206c6f6f6b20736d617274 492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f7368690a492077696c6c206e6f7420776f727368697020612066616c7365207361746f736869 4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b0a4920616d206e6f74206120464449432d696e73757265642062616e6b 48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d69780a48696768206578706c6f736976657320616e64206d61696c20646f6e2774206d6978 5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d650a5468657920617265206c61756768696e67206174206d652c206e6f742077697468206d65 
Looking more closely at these scripts, we see that there are repeating sequences, and they are different lengths. This means that it isn't just random garbage. Well the first thing to try is to see if this hex results in any ascii, and what do you know, this is what we get for the first string:
I will not clone Bitcoin for personal gain I will not clone Bitcoin for personal gain I will not clone Bitcoin for personal gain I will not clone Bitcoin for personal gain 
Huh. That's interesting. I think someone is being mocked. Lets see what the rest are:
I will not use assert(0) for input validation I will not use assert(0) for input validation I will not use assert(0) for input validation Writing gibberish equations on a blackboard does not make me look smart Writing gibberish equations on a blackboard does not make me look smart I will not worship a false satoshi I will not worship a false satoshi I will not worship a false satoshi I will not worship a false satoshi I am not a FDIC-insured bank I am not a FDIC-insured bank I am not a FDIC-insured bank I am not a FDIC-insured bank I am not a FDIC-insured bank High explosives and mail don't mix High explosives and mail don't mix High explosives and mail don't mix High explosives and mail don't mix They are laughing at me, not with me They are laughing at me, not with me They are laughing at me, not with me They are laughing at me, not with me 
So it seems that someone is just mocking you all. They have put these mocking strings in a redeemScript and require you to repeat them in order to spend them. This kind of reminds me of Bart Simpson performing his punishment of writing sentences over and over on a chalkboard. The other thing that this does is that in order to clean up the thousands of outputs, you will need to spend 10 kB per output, which will severely bloat your blockchain. Or you can just leave them in the UTXO set which will bloat the UTXO set with dust. But what to do with these is something you all will need to deal with, I'm just here to see what was up with these transactions.
As for why these transactions don't work for _chjj's attack, they require that the spending transactions be very large. But that is not ideal because for that attack to work, the spends need to be very small so that more spends can fit in one block which will increase memory usage. These transactions are not good for that since you can only fit a much smaller number of transactions in a block so the memory blow up is way less.
Edit: I don't support Bitcoin Cash, which is why I say that this is "your problem". I just thought this was interesting as it looked like it could impact Bitcoin as well, which is why I investigated this.
submitted by achow101 to btc [link] [comments]

A reminder why CryptoNote protocol was created...

CryptoNote v 2.0 Nicolas van Saberhagen October 17, 2013
1 Introduction
“Bitcoin” [1] has been a successful implementation of the concept of p2p electronic cash. Both professionals and the general public have come to appreciate the convenient combination of public transactions and proof-of-work as a trust model. Today, the user base of electronic cash is growing at a steady pace; customers are attracted to low fees and the anonymity provided by electronic cash and merchants value its predicted and decentralized emission. Bitcoin has effectively proved that electronic cash can be as simple as paper money and as convenient as credit cards.
Unfortunately, Bitcoin suffers from several deficiencies. For example, the system’s distributed nature is inflexible, preventing the implementation of new features until almost all of the net- work users update their clients. Some critical flaws that cannot be fixed rapidly deter Bitcoin’s widespread propagation. In such inflexible models, it is more efficient to roll-out a new project rather than perpetually fix the original project.
In this paper, we study and propose solutions to the main deficiencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among different electronic cash systems. We also propose our own electronic cash, “CryptoNote”, a name emphasizing the next breakthrough in electronic cash.
2 Bitcoin drawbacks and some possible solutions
2.1 Traceability of transactions
Privacy and anonymity are the most important aspects of electronic cash. Peer-to-peer payments seek to be concealed from third party’s view, a distinct difference when compared with traditional banking. In particular, T. Okamoto and K. Ohta described six criteria of ideal electronic cash, which included “privacy: relationship between the user and his purchases must be untraceable by anyone” [30]. From their description, we derived two properties which a fully anonymous electronic cash model must satisfy in order to comply with the requirements outlined by Okamoto and Ohta:
Untraceability: for each incoming transaction all possible senders are equiprobable.
Unlinkability: for any two outgoing transactions it is impossible to prove they were sent to the same person.
Unfortunately, Bitcoin does not satisfy the untraceability requirement. Since all the trans- actions that take place between the network’s participants are public, any transaction can be unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final recipient.
It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database.
Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suffers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5].
2.2 The proof-of-work function
Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “one- CPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system.
The security of this model suffers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug fixes, security fixes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7].
This permits us to conjecture the properties that must be satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more efficient on GPUs and ASIC devices when compared to high-end CPUs.
Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes.
One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat flawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains significant mining power by creating his own mining farm through the cheap hardware described previously. Suppose that the global hashrate decreases significantly, even for a moment, he can now use his mining power to fork the chain and double-spend. As we shall see later in this article, it is not unlikely for the previously described event to take place.
2.3 Irregular emission
Bitcoin has a predetermined emission rate: each solved block produces a fixed amount of coins. Approximately every four years this reward is halved. The original intention was to create a limited smooth emission with exponential decay, but in fact we have a piecewise linear emission function whose breakpoints may cause problems to the Bitcoin infrastructure.
When the breakpoint occurs, miners start to receive only half of the value of their previous reward. The absolute difference between 12.5 and 6.25 BTC (projected for the year 2020) may seem tolerable. However, when examining the 50 to 25 BTC drop that took place on November 28 2012, felt inappropriate for a significant number of members of the mining community. Figure 1 shows a dramatic decrease in the network’s hashrate in the end of November, exactly when the halving took place. This event could have been the perfect moment for the malevolent individual described in the proof-of-work function section to carry-out a double spending attack [36]. Fig. 1. Bitcoin hashrate chart (source: http://bitcoin.sipa.be)
2.4 Hardcoded constants
Bitcoin has many hard-coded limits, where some are natural elements of the original design (e.g. block frequency, maximum amount of money supply, number of confirmations) whereas other seem to be artificial constraints. It is not so much the limits, as the inability of quickly changing them if necessary that causes the main drawbacks. Unfortunately, it is hard to predict when the constants may need to be changed and replacing them may lead to terrible consequences.
A good example of a hardcoded limit change leading to disastrous consequences is the block size limit set to 250kb1. This limit was sufficient to hold about 10000 standard transactions. In early 2013, this limit had almost been reached and an agreement was reached to increase the limit. The change was implemented in wallet version 0.8 and ended with a 24-blocks chain split and a successful double-spend attack [9]. While the bug was not in the Bitcoin protocol, but rather in the database engine it could have been easily caught by a simple stress test if there was no artificially introduced block size limit.
Constants also act as a form of centralization point. Despite the peer-to-peer nature of Bitcoin, an overwhelming majority of nodes use the official reference client [10] developed by a small group of people. This group makes the decision to implement changes to the protocol and most people accept these changes irrespective of their “correctness”. Some decisions caused heated discussions and even calls for boycott [11], which indicates that the community and the developers may disagree on some important points. It therefore seems logical to have a protocol with user-configurable and self-adjusting variables as a possible way to avoid these problems.
2.5 Bulky scripts
The scripting system in Bitcoin is a heavy and complex feature. It potentially allows one to create sophisticated transactions [12], but some of its features are disabled due to security concerns and some have never even been used [13]. The script (including both senders’ and receivers’ parts) for the most popular transaction in Bitcoin looks like this: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. The script is 164 bytes long whereas its only purpose is to check if the receiver possess the secret key required to verify his signature.
Read the rest of the white paper here: https://cryptonote.org/whitepaper.pdf
submitted by xmrhaelan to CryptoCurrency [link] [comments]

What's the f*****ng benefit of the reactivated OP_Codes?

Nobody explained what we can do with the soon to be reactivated OP_Codes for Bitcoin Cash, and nobody explained why we need them. It's a fact that there are risks associated with them, and there is no sufficient testing of these risks by independent developers, nor is there a sufficient explanation why they carry no risk. BitcoinABC developers, explain yourselves, please.
Edit: Instead of calling me a troll, please answer the question. If not, ask someone else.
Edit Edit: tomtomtom7 provided a resfreshing answer on the question:
https://www.reddit.com/btc/comments/7z3ly4/to_the_people_who_thing_we_urgently_need_to_add/dulkmnf/
The OP_Codes were disabled because bugs were found, and worry existed that more bugs could exist.
They are now being re-enabled with these bugs fixed, with sufficient test cases and they will be put through thorough review.
These are missing pieces in the language for which various use cases have been proposed over the years.
The reason to include these, is because all developers from various implementations have agreed that this is a good idea. No objections are raised.
Note that this does not mean that all these OP_Codes will make it in the next hardfork. This is obviously uncertain when testing and reviewing is still being done.
This is not yet the case for OP_GROUP. Some objection and questions have been raised which takes time to discuss and time to come to agreement. IMO this is a very healthy process.
Another good comment is here
https://www.reddit.com/btc/comments/7z49at/whats_the_fng_benefit_of_the_reactivated_op_codes/dullcek/
One precise thing: Allowing more bitwise logical operators can (will) yield smaller scripts, this saves data on the blockchain, the hex code gets smaller.
Here is a detailled answer. I did not goe through it if it is satisfying, but at least it is a very good start, Thank you silverjustice.
But further, if you want specific advantages for some of these, then I recommend you check out the below from the scaling Bitcoin conference:
opcodes are very useful, such as in for example with CAT you can do tree signatures even if you have a very complicated multisig design using CAT you could reduce that size to log(n) size. It would be much more compact. Or with XOR we could do some kind of deterministic random number generator by combining secret values from different parties so that nobody could cheat. They could combine and generate a new random number. If people think-- ... we could use LEFT to make weaker hash. These opcodes were re-enabled in sidechain elements project. It's a sidechain from Bitcoin Core. We can reintroduce these functions to bitcoin.
The other problem are the ... numeric operations which were disabled by Satoshi. There's another problem. Which is that the range of values accepted by script is limited and confused because the CScript.. is processed at ..... bit integers internally. But to these opcodes it's only 32 bits at most. So it's quite confusing. The other problem is that we have this.. it requires 251 encode or calculate or manipulate this number. So we need at least 52 bits. But right now it is only 32 bits. So the proposal is to expand the valid input range to 7 bytes which would allow 56 bits. And it limits the maximum size to 7 bytes so we could have the same size for inputs and outputs. For these operations, we could re-enable them within these safe limits. It would be safe for us to have these functions again.
The other problem is that we currently cannot commit to additional scripts. In the original design of bitcoin, we could have script operations inside of the signature. But the problem is that the signature is not covered by the signature itself. So any script in the scriptSig is modifiable by any third party in the network. For example, if we tried to do a CHECKSIG operation in the signature, people could simply replace it with an OP_0 and invalidate the transaction. This is a bypass of the.. signature check in the scriptSig. But actually this function is really useful, for example, we can do... delegation, people could add additional scripts to a new UTXO without first spending it. So people could do something like let's say to let their son spend their coin within a year if it is not first spent otherwise.. and also, people, talk about replay protection. So we have some ohter new opcode like pushing the blockhash to the stack, with this function we could have replay protection to make sure the transaction is valid only in a specified blockchain.
So the proposal is that in the future the CHECKSIG should have the ability to sign additional script and to execute these scripts. And finally the other problem is that the script has limited access to different parts of the transaction. There is only one type of operation that allowed to investigate different parts of the transaction, which is CHECKSIG and CHECKMULTISIG. But it is very limited. There are sighash limitations here... there are only 6 types of sighash. The advantage of doing this is that it's very compact and could use only one byte to indicate which component to sign. But the problem is that it's inflexible. The meaning of this sighash is set at the beginning and you can't change it. You need a new witness version to have another checksig. And the other problem is that the sighash can be complex and people might make mistakes so Satoshi made this mistake in the sighash design such as the well-known bug in validation time and also the SIGHASH_SINGLE bug. It's not easy to prevent.
The proposal is that we might have the next generation of sighash (sighashv2) to expand to two bytes, allow it to cover different parts of the transaction and allow people to choose which components they would like to sign. This would allow more flexibility and hopefully not overly complicated. But still this is probably not enough for more flexible design.
Another proposal is OP_PUSHTXDATA which pushes the value of different components of a transaction to the stack. It's easy to implement, for example, we could just push the scriptpubkey of the second output to the stack, okay. So it is actually easier to implement. We could do something more than just... because we have sighash, we could check where something is equal to the specified value. But if we could push the value, like the value of an output to the stack, then we could use other operations like more than or less than and then we could do something like checking whether the value of output x must be at least y bitcoin, which is a fixed value.
There are some other useful functions like MAST which would allow for more compact scripts by hiding the other unexecuted branches. There's also aggregation that would allow n-of-n multisig to be reduced to a single signature and so on. In the elements project, they implemented CHECKSIGFROMSTACK where they don't check the transaction structure but instead they verify a message on the stack. So it could be some message like not bitcoin maybe, perhaps cross-chain swap, or another bitcoin UTXO. And also we might have some elliptic curve point addition and operations which are also useful in lightning network design.
Here are some related works in progress. If you are interested in this topic, I would like to encourage you to join our discussions because it's a very active topic. jl2012 bip114 MAST, maaku's MBV, luke-jr or version-1 witness program, Simplicity, etc.
so you have your script template the amount value and there is a block impactor beause we have the sha chain whih allows you to hae the hashes.. we can hae that errortate constant beause you need the HTLC chashes, to properly reoke the prior states and if you an't do that then you can't onstruct the redeem script. Right now it ineeds a signature for eery state, you need all the HTLCs, it needs the netowrk erification state, and there's another cool thing you can do with which is like trap door erification and you can include it in the transaction itself and there can be a alsue where there is some margin for it.. Which make sit powerful, and then you can make it more private with these constructs. We only have a few minutes left, we can cover this.
One furthe rthing is that in the transformation, we have privacy issue because we need to keep going forward, we need to have hte private state, so there's a history of this in the ages in the past, the current one used replications, which was one of the cool things about lightning. We used to have deckman signatures we had a sequence value of like 30 days, we did an update, we had to switch sides then we make it 29 then 27 etc. You can only broadcast the most recent state because otherwise the other party can transact the other transaction. If you start with 30 days then you can only do about 30 bidirectiona lswitches. Then there was cdecker's payment channels where you have a root tree and every time you need to- you had two payment channels, you had to rebalance htem and then it's on your part of the channel you can reset the channel state. You can do 30 this way, you have another tree, you can do it that way, and then there's a new version of it in the indefinite lifetime... by keeping the transaction in CSV, the drawback on that paproahc because you have al arge validation tree, in the worst cas eyou have 8 or 10 on the tree, and then you nee dfor the prior state and then you do the 12 per day, and every time you have to make a state, you have to revoke the preimage from the prior state, this is cool because if they ever broadcast the entire state, eahc one has the caluse so that you can draw the entire money in the event o f a violation. There are some limitations for doing more complex verifications and you have this log(n) state that you have to deal with ehen you deal with that.
We're going to do the key power on the stack to limit key verifications on this main contract. this is all composable. You can do discreet log contracts. You can now check signtures on arbitrary messages. You can sign a message nad then we can enforce structure on the messages themselves. Right now you need to have sequene numbers. So each state we are going to increment the sequence numbers. So you give me a siequence number on that state. On the touputs we have a commitment ot the sequence number and the value r. So people on chain will know that how many places we did in that itself. The ool part about this is that because we have a seq number then I have the one if it's highest neough. Then I am opening that commitment to say this is state 5 and I present to you a new signed ommitment and open that as well, that's in a validation state. The cool things is that you only need one of those m. So we have to some auxiliary state, and each time I have a new state I an drop the old state. I have a signed commitment to revoke the prior state. This is a ibg deal beause the state is much smaller. Currently we require you to fwe use a state mahcine on state 2, and it also has implications for verifications and watch tower
So on lightning, there's this technique itself- it's timelocks CSV value and if you can't react within that value then you can't go to court and enforce judgement on this attacker. So the watchtower is a requirement, you delegate the state watching to the watchtower. They know which channels you're watching. You send some initial points, like a script template. For every one you send the signautre and the verification state. They can use the verification stat ethat collapses into a log(n) tree, you can basically use state where you send half the txids, you can decrypt this in... some time.
submitted by Der_Bergmann to btc [link] [comments]

/u/Septem_151 on Cybercash, as imagined in 1998

TL;DR: A Transaction Input is what reveals your public key, not the Transaction Output, and an address represents the hash of a Public Key.
UTXOs that are P2PKH (Pay to Pub Key Hash) go to the hash of a public key. More specifically, the following script, known as the scriptPubKey, is pushed onto a stack: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
These operations define how the coins are allowed to be spent. OP_DUP = Duplicate the top item of the stack, OP_HASH160 = Popping the top of the stack and pushing the RIPEMD-160 hash of the SHA-256 hash of the popped data back onto the stack, = Pushing the recipient’s decoded Address onto the stack, OP_EQUALVERIFY = checking if the top two values on the stack are equal and popping them if true, and OP_CHECKSIG = checks if the signature is verified by the public key on the stack (more on this later). For more information, check the bitcoin wiki’s section on bitcoin script.
A legacy bitcoin address (beginning with a 1) is just a public key hash that is encoded in Base58 with a version byte (0x00) prepended, and a checksum appended to the end. To convert an address to a PubKeyHash is as simple as decoding from Base58.
However, when a UTXO is Spent, the spender must prove ownership by providing some additional values to satisfy the UTXO’s scriptPubKey. This combination of values is known as the scriptSig, and for P2PKH consists of two parts: Signature>
When a Transaction is evaluated and verified, the input’s scriptSig and the scriptPubKey of the output it’s spending are placed onto a stack so the whole thing becomes: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
First, the signature is pushed to the stack. Then the public key associated with the bitcoin address. OP_DUP duplicates the public key, OP_HASH160 pops the public key off the stack and pushes the hash of the public key onto the stack. Then the PubKeyHash whom the coins belongs to is pushed to the stack. Then OP_EQUALVERIFY checks to see if the public key does indeed hash to the specified PubKeyHash. If true, the two values are popped off the stack. Then OP_CHECKSIG takes the last two elements from the stack (the signature and the unhashed public key) and checks if the signature is valid. If true, the input is valid and “unlocks” the UTXO for spending.
This is a big part of why you should not reuse addresses: only when you SPEND a UTXO do you reveal your Public Key to the world. Until spent, your public key is secured behind other barriers (SHA-256 and RIPEMD-160). If Elliptic Curve cryptography is to be broken by quantum computers, it will also need to break the hashing algorithms above as well to at least invalidate P2PKH outputs. Back in the very early days, some Outputs were made using P2PK (Pay to Pub Key) which does not use this intermediary hashing technique and is considered far less secure, thus it is rarely used today if at all.
Septem_151
submitted by highhighhopes101 to TalkativePeople [link] [comments]

As part of my ongoing effort to develop stupid shit for Garlicoin, I present you: W-addresses!

“Wait, what?!” I hear you asking? Well…(buckle up, this is another one of my technical posts that goes on, and on…)
For some time now, I have been using native SegWit (Pay-to-Witness-Public-Key-Hash, P2WPKH) transactions for myself. Mostly because they have a 75% fee subsidy on signature data (which comes out on ~50% fee subsidy on the entire transaction, depending on the type of transaction) and I am dutch after all ;-)
It turns out that Garlicoin Core kind of supports them and kind of does not. If you manually register the transaction redeem script to your wallet (using the addwitnessaddress command) it will start recognizing them on the blockchain but gets kind of confused on how to deal with them, so it registers them all as ‘change’ transactions. Still, this means you can receive coins using these types of transactions and pay with them in all ways you can with regular Garlicoins, except your transactions are cheaper.
However, sending coins using native SegWit is quite a hassle. You can basically only do it by creating your own raw transactions (createrawtransaction, edit it to make it native SegWit, fundrawtransaction, signrawtransaction, sendrawtransaction). On top of this, any change address the wallet creates are still legacy/normal Garlicoin addresses, so you will end up with a bunch of unspent transaction outputs (UTXOs) for which you have to pay full fee anyway. I decided we (I) could do better than this.
But first a few steps back. What is this native SegWit anyway and weren’t people already using SegWit? Wasn’t there a user that just after mainnet launched accidentally made a SegWit transaction? So what the hell am I talking about?
To understand this, you will need to know a few things about what SegWit is and how Bitcoin Garlicoin transactions work in general. Note that this bit gets really technical, so if you are not interested, you might want to skip ahead. A lot.
First thing to understand is that addresses are not really a thing if you look at the blockchain. While nodes and explorers will interpret parts of a transaction as addresses, in reality addresses are just an abstraction around Bitcoin Script and an easy way send coins instead of asking people “hey, can you send some coins to the network in such a way that only the private key that corresponds to public key XYZ can unlock them?”. Let’s look at an example: say I ask you to send coins to my address GR1Vcgj2r6EjGQJHHGkAUr1XnidA19MrxC. What ends up happening is that you send coins out a transaction where you say that the coin are locked in the blockchain and can only be unlocked by successfully executing the following script:
OP_DUP OP_HASH160 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050 OP_EQUALVERIFY OP_CHECKSIG
Now, without getting too technical, this means something like this:
As you can see, the address actually represents a well-known piece of script. This start making sense if you look at the decoded address:
26 4E9856671C3ABB2F03B7D80B9238E8F5ECD9F050 F8F1F945
The first byte (0x26, or 38) is the version byte. This tells the clients how the interpret the rest of the script. In our case 38 means Pay-to-Public-Key-Hash (P2PKH), or in other words the script mentioned above. The part after that is just the SHA1 hash of the public key and the final 4 bytes are a checksum to verify you did not make a typo when entering the address.
Enter SegWit. What SegWit exactly is depends on who you are talking to, however it mostly is a different transaction format/protocol. The main change of SegWit is that signature data is not longer included in the transaction (fixing transaction malleability). Instead transaction data is sent separate from the transaction itself and outside of the (main) blocks.
This is not really that much of an issue, except for the fact that people wanted to enable SegWit as a soft-fork instead of a hard-fork. This means that somehow unupgraded nodes needed a way to deal with these new transaction types without being able to verify them.
The solution turned out to be to make use of an implementation detail of Bitcoin Script: if a piece of script executes without any errors, the last bit of data determines whether the transaction is valid (non-zero) or invalid (zero). This is what they used to implement SegWit.
So what does this look like? Well, you might be surprised how simple a P2WPKH (the SegWit way of doing a P2PKH transaction) script looks:
00 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050
Yes. That’s it.
The first byte is the Witness program version byte. I.e. it tells you how the other data should be interpreted (very similar to how addresses work). Then there is the hash of the public key. As you can see, SegWit does not actually use Bitcoin Script. Mostly because it needs old nodes to ‘just accept’ its transactions. However interestingly enough, while the transaction format changed, the transaction data is pretty much the same:
This means that these kind of SegWit transactions need a new way of addressing them. Now, you might think that this is where the ‘3’ addresses on Bitcoin or the ‘M’ addresses on Garlicoin come in. However, that is not the case.
These addresses are what are called Pay-to-Script-Hash (P2SH) addresses. There scrypt is like this:
OP_HASH160 35521b9e015240942ad6b0735c6e7365354b0794 OP_EQUAL
Huh? Yeah, these are a very special type of transactions, that kind of go back to the “hey, can you send some coins to the network in such a way that only the private key that corresponds to public key XYZ can unlock them?” issue.
These transactions are a way to have arbitrary smart contracts (within the limits of Bitcoin Script) to determine whether a transaction output can be spend or not without the sender of the coins having to deal with your scripts. Basically they use a hash of the “real” script, which whoever owns the coins has to provide when they want to spend them, as well as the specific inputs required for a script. This functionality is for example used in multi-signature (MultiSig) wallets, without requiring someone sending money to these wallets having to deal with random bits of information like how many signatures are required, how many private keys belong to the wallet, etc.
This same method is used for so called P2SH-wrapped SegWit transactions (or P2SH-P2WPKH). Consider our earlier SegWit transaction output script:
00 4e9856671c3abb2f03b7d80b9238e8f5ecd9f050
Or 00144e9856671c3abb2f03b7d80b9238e8f5ecd9f050 in low-level hex. The P2SH script for this would be:
OP_HASH160 a059c8385124aa273dd3feaf52f4d94d42f01796 OP_EQUAL
Which would give us address MNX1uHyAQMXsGiGt5wACiyMUgjHn1qk1Kw. This is what is now widely known and used as SegWit. But this is P2SH-wrapper SegWit, not native or "real" SegWit. Native would be using the data-only SegWit script directly.
The reason for using the P2SH variant is mostly about compatibility. While SegWit nodes understand these newer transactions, they were never officially assigned a way to convert them to addresses. Hence, they will show up in blockchain explorers as Unparsed address [0] or something similar. Then there is also the whole thing about old nodes and relaying non-standard transactions, but I will skip that bit for now.
Bitcoin is using/going to use new BECH32 addresses for native SegWit transactions, which looks completely different from the old Base-58 encoded addresses. However, right now, especially on Garlicoin, you cannot really use them and have to use the P2SH variant. But why not use these new cool transaction types without having to deal with all that useless and complex P2SH wrapping, right? Right? …
Well, I went ahead and gave them their (unofficial) address space.
So last thursday I made some changes to Garlicoin Core, to make dealing with these native SegWit transaction a lot easier. In short, the changes consist of:
  • Assigning address version byte 73 to them, in other words addresses starting with a ‘W’ (for ‘witness’).
  • Allowing the use of ‘W’ addresses when sending coins.
  • Make the wallet automatically recognize the SegWit transaction type for any newly generated address.
  • Add the getwitnessaddress command, which decodes a version 38 ‘G’ address and re-encodes the same data as a version 73 ‘W’ address (unfortunately it is not as simple as just changing the first letter). Note that this can be any address, not just your own. (That said, you should not send SegWit transactions to people not expecting them, always use the address given to you.)
  • Added the usewitnesschangeaddress configuration setting, to automatically use the cheaper SegWit transaction outputs for transaction change outputs.
  • (Since using the 'W' address only changes the way coins are sent to you and the private key used for both transaction types is the same:) When receiving coins they show all up under the original ‘G’ address, whether a SegWit or legacy/normal transaction type was used. The idea behind this is that both are actually the same "physical" (?) address, just to the way to coins to it differs. Address book entries are also merged and default to the ‘G’ address type.
Anyway, I don’t expect people to actually use this or it getting merged into mainline or anything. I actually mostly made this for myself, but thought I should share anyway. I guess it was also a nice opportunity to talk a bit about transactions and SegWit. :-)
Btw, I also changed my pool to allow mining to ‘W’ addresses, to make coin consolidation cheaper (due to the SegWit fee subsidy). Right now this is only for instant payout though (as I would have to update the wallet node the pool is using for daily payout, which I haven’t done yet).
Also note that you can actually mine to a ‘W’ address (and therefore use cheaper transactions) even if you are running the official, non-patched version of Garlicoin Core, however:
  • You need to manually convert your ‘G’ address to a ‘W’ address.
  • You need to run the addwitnessaddress command (Help -> Debug Window -> Console) to make the wallet recognize SegWit transactions (you can ignore the ‘M’ address it produces).
  • The wallet might get a bit confused as it does not really understand how it got the coins. This is mostly notable in the ‘Coin Control’ window if you have it enabled. Apart from that everything should still work though.
submitted by nuc1e4r5n4k3 to garlicoin [link] [comments]

How Craig constructed the "message" that he "signed" using Satoshi's key

Craig was a bit clever here. He did not cheat, and did not use modified command line tools. He indeed posted a message signed by Satoshi's key, that validates correctly. This might explain how he fooled a few people. However, that message just so happens to be a hash of an early Bitcoin transaction, not anything proving his identity. Here's how he did it.
First, check out Dan Kaminsky's blogpost for less-stupid instructions and an archive of the files you need (instead of having to transcribe hex from Craig's post). Although Dan concludes that the signature does not validate, that's actually only due to the & vs. && bug in the last bash command. If you run the corrected command, it works:
$ base64 --decode signiture.der > sig.asn1 && openssl dgst -verify sn-pub.pem -signature sig.asn1 sn7-message.txt Verified OK 
What's the signed message? This:
$ xxd sn7-message.txt 00000000: 479f 9dff 0155 c045 da78 4021 7785 5fdb [email protected]!w._. 00000010: 4f0f 396d c0d2 c24f 7376 dd56 e2e6 8b05 O.9m...Osv.V.... 
That's just binary junk. It was really signed by Satoshi though.
We now know that the signature turned out to correspond to a real Bitcoin transaction (credit to JoukeH). Compare its input script with:
$ xxd sig.asn1 00000000: 3045 0221 00c1 2a7d 5497 2f26 d14c b311 0E.!..*}T./&.L.. 00000010: 339b 5122 f8c1 8741 7dde 1e8e fb68 41f5 3.Q"...A}....hA. 00000020: 5c34 220a e002 2066 632c 5cd4 161e fa3a \4"... fc,\....: 00000030: 2837 764e ee9e b849 75dd 54c2 de28 65e9 (7vN...Iu.T..(e. 00000040: 7525 85c5 3e7c ce u%..>|. 
So where did sn7-message.txt come from? To put it together, we need to follow the OP_CHECKSIG documentation. Specifically, the message to be signed is the transaction, but with the input script replaced with the output script of the transaction that sent the coins in the first place, plus the hash type value of '1'.
First we download the two transactions:
$ curl -so send.bin https://webbtc.com/tx/12b5633bad1f9c167d523ad1aa1947b2732a865bf5414eab2f9e5ae5d5c191ba.bin $ curl -so spend.bin https://webbtc.com/tx/828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe.bin 
Then we dike out the script bit from send.bin and insert it into spend.bin, replacing the input script, and append '1' as a 32-bit little endian integer:
$ head -c 41 spend.bin >sig_txn.bin $ dd if=send.bin bs=1 skip=204 count=68 status=none >>sig_txn.bin $ tail -c 161 spend.bin >>sig_txn.bin $ echo -ne '\x01\x00\x00\x00' >>sig_txn.bin 
Take the SHA-256 hash and there you go:
$ sha256sum sig_txn.bin 479f9dff0155c045da78402177855fdb4f0f396dc0d2c24f7376dd56e2e68b05 sig_txn.bin 
You can also validate this against the Signature Hash field in webbtc's script debug view. Bitcoin actually does a double SHA-256 here, once as part of the protocol, and once as part of the elliptic curve code. So apply sha256sum again:
$ sha256sum sn7-message.txt 3ec9cbc0d1aa849c16a1b276b246e057e7232b21926e428cc09b692c14336f44 sn7-message.txt 
... and you get the Signature Hash.
Interestingly, the source address of this transaction (the bit cut out from send.bin) is the same as in the example on the OP_CHECKSIG documentation wiki page - so he was too lazy even to pick another address, although he picked a different spend transaction.
This is what us security guys call a replay attack. Well played, Craig.
Edits: links and spelling.
Edit2: to make it clear, as bedstefar points out, this doesn't prove that Craig is not Satoshi. It only proves that his blog post doesn't prove that he is Satoshi, and anyone could've written a similar blog post.
Edit3: the blog post does claim that the (incompletely displayed, unverifiable) Sartre text hashes to the same hash as my sig_txn.bin. That much is obviously a lie and patent nonsense, unless you believe he's the first person in the world to come up with a SHA-256 preimage attack. He didn't have to doctor any screenshots or tools for that, the lie is that where he says "The contents of this file have been displayed in the figure below." he's displaying the contents of a different file.
Edit4: Wow, thanks for the gold!
submitted by marcan42 to Bitcoin [link] [comments]

Bitcoin 2010 vulnerability

Hello I am entering in this world and always curios and curious to analize vulnerabilities. Here there is the 2010 bitcoin vulnerability which I didn't full understand, can someone help me to understand?
https://bitcointalk.org/index.php?topic=822.0
The "value out" in this block #74638 is quite strange:
{"hash" : "0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c","ver" : 1,"prev_block" : "0000000000606865e679308edf079991764d88e8122ca9250aef5386962b6e84","mrkl_root" : "618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e","time" : 1281891957,"bits" : 469794830,"nonce" : 28192719,"n_tx" : 2,"tx" : [{"hash" : "012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca","ver" : 1,"vin_sz" : 1,"vout_sz" : 1,"lock_time" : 0,"in" : [{"prev_out" : {"hash" : "0000000000000000000000000000000000000000000000000000000000000000","n" : 4294967295},"coinbase" : "040e80001c028f00"}],"out" : [{"value" : 50.51000000,"scriptPubKey" : "0x4F4BA55D1580F8C3A8A2C78E8B7963837C7EA2BD8654B9D96C51994E6FCF6E65E1CF9A844B044EEA125F26C26DBB1B207E4C3F2A098989DA9BA5BA455E830F7504 OP_CHECKSIG"}]},{"hash" : "1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9","ver" : 1,"vin_sz" : 1,"vout_sz" : 2,"lock_time" : 0,"in" : [{"prev_out" : {"hash" : "237fe8348fc77ace11049931058abb034c99698c7fe99b1cc022b1365a705d39","n" : 0},"scriptSig" : "0xA87C02384E1F184B79C6ACF070BEA45D5B6A4739DBFF776A5D8CE11B23532DD05A20029387F6E4E77360692BB624EEC1664A21A42AA8FC16AEB9BD807A4698D0CA8CDB0021024530 0x965D33950A28B84C9C19AB64BAE9410875C537F0EB29D1D21A60DA7BAD2706FBADA7DF5E84F645063715B7D0472ABB9EBFDE5CE7D9A74C7F207929EDAE975D6B04"}],"out" : [{"value" : 92233720368.54277039,"scriptPubKey" : "OP_DUP OP_HASH160 0xB7A73EB128D7EA3D388DB12418302A1CBAD5E890 OP_EQUALVERIFY OP_CHECKSIG"},{"value" : 92233720368.54277039,"scriptPubKey" : "OP_DUP OP_HASH160 0x151275508C66F89DEC2C5F43B6F9CBE0B5C4722C OP_EQUALVERIFY OP_CHECKSIG"}]}],"mrkl_tree" : ["012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca","1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9","618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e"
]
}
This could be a serious problem. Bitcoin's printblock also shows it:
CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba, nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)vMerkleTree: 012cd8 1d5e51 618eba
I have a serie of questions:
  1. What is this language? which kind of language is it?
  2. the POCO i this:
''Essentially, the code for checking Bitcoin transactions did not work if outputs were so large that they overflowed when summed, and a hacker figured this out and took advantage of it. There is supposed to be a fixed maximum supply of 21 million Bitcoin, but the hacker, in a single transaction, created 8,784 times more Bitcoins than ever should exist.''

What does it mean ''did not work if outputs were so large'' ? The output of what?
so large that they overflowed when summed ...
what does this mean? can you make an example to let me understand?
The sum of what + what? And why does this sum caused a bufferoverflow? A buffer overflow isn't it when for example there is an array and then there is no definied lenght for the array and you put in more than the array may own? In this case from what is the buffer overflow caused by?
Also interstead in what does this string mean:
vMerkleTree: 012cd8 1d5e51 618eba
what does this mean?
submitted by luchins to HowToHack [link] [comments]

Non Standard Transaction Redeem Script

If I decide to use non standard transaction in main chain, I wonder is there are some miner pool who accept such transactions?This script should be used as deposit escrow transaction of buyer during trade circle (paypal - btc)."a" is seller, "b" is escrow service, "c" is buyer who must make first deposit transaction before hi can buy btc instantly.Limit per transaction is determined by transaction input, if buyer goes crazy to reverse transaction, seller should track and supply ipn messages as proof to escrow service reveling the scammer and taking his bitcoin back.Before 365 days expire, btc can be spent, but signature of "b" (escrow service) must be included.180 days is limit time for reporting "unauthorized transaction", so buyer will be able to buy 180 days btc instantly after deposit transaction.Still thinking on making the script better, but any effort will be waste of time if I do not find a way to include spend transaction in the block.
Any comment on script below would be helpful too. :)
OP_IF 365days OP_CHECKSEQUENCEVERIFY OP_DROP  OP_CHECKSIG OP_ELSE OP_DUP  OP_CHECKSIGVERIFY 2    3 OP_CHECKMULTISIG OP_ENDIF 
Update:
OP_IF 365days OP_CHECKSEQUENCEVERIFY OP_DROP  OP_CHECKSIG OP_ELSE  OP_CHECKSIGVERIFY 1   2 OP_CHECKMULTISIG OP_ENDIF 
Next proposal:
OP_DUP  OP_CHECKSIG OP_IF OP_DROP 1   2 OP_CHECKMULTISIG OP_ELSE 365days OP_CHECKSEQUENCEVERIFY OP_DROP  OP_CHECKSIG OP_ENDIF 
Update:
I feeling very disappointed.I did not find any way to add non standard transaction into block, even each fork did not go far a way for current btc, they are just forks working on scaling dist space, just like core developers waiting for lighting make there lives easier.
Bitcoin is peer-to-peer cash.
But to become that truly, we must handle current "working" cash, right?Banks, payment processors are blackmailing the people who would like to use this money (of the future), and we allowing them to do it with no problem.You can not put primitive multisig as only complex standard, exclude any alternative and expect from exchanges to work correctly and not being hacked.
Exchanges can not work with primitive multisig and can not work with any of "standard" transaction on the current list in a way to provide secured exit from fiat to crypto.Exchanges are hacked in one way or another. By simulating breach or being hacked for real.Most of exchanges being hacked are still working as before, same as banks, no jail, no money.Basically it is a same sh*t as we have seen in bank bail-in scenario. Nothing is changed.
Bitcoin is able to transfer ownership over the value from one owner to another by building and using trust less, decentralized, censorship resistant environment and all that is possible by math, not by power of central authority.
So exchanges should be able to handle that in a same way, not by collecting bitcoins and store them in the chest like banks do and repeating "everything is alright and we will not be hacked for now"
It is useless if we can not provide real exit way for other peoples who waiting for it.
*MAKE "STANDARD" TRANSACTION LIST LONGER, SO EXCHANGES CAN HANDLE "non authorized bank account transactions", etc..."*
submitted by zninja-bg to Bitcoin [link] [comments]

The Problems with Segregated Witness

MORE: https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
... 3. The Problems with Segregated Witness
While it is true that Segregated Witness offers some improvements to the Bitcoin network, we shall now examine why these benefits are not nearly enough to outweigh the dangers of deploying SW as a soft fork.
3.1 SW creates a financial incentive for bloating witness data
SW allows for a theoretical maximum block size limit of ~4 MB. However, this is only true if the entire block was occupied with transactions of a very small ‘base size’ (e.g. P2WPKH with 1 input, 1 output). In practice, based on the average transaction size today and the types of transactions made, the block size limit is expected to have a maximum limit of ~1.7 MB post-SW (Figure 10; assuming all transactions are using SW unspent outputs — a big assumption).
However, the 4 MB theoretical limit creates a key problem. Miners and full node operators need to ensure that their systems can handle the 4 MB limit, even though at best they will only be able to support ~40% of that transaction capacity. Why? Because there exists a financial incentive for malicious actors to design transactions with a small base size but large and complex witness data. This is exacerbated by the fact that witness scripts (i.e. P2SH-P2WSH or P2SH-P2WSH) will have higher script size limits that normal P2SH redeem scripts (i.e., from 520 bytes to 3,600 bytes [policy] or 10,000 bytes [consensus]). These potential problems only worsen as the block size limit is raised in the future, for example a 2 MB maximum base size creates an 8 MB adversarial case. This problem hinders scalability and makes future capacity increases more difficult.
3.2 SW fails to sufficiently address the problems it intends to solve
If SW is activated by soft fork, Bitcoin will effectively have two classes of UTXOs (non-SW vs SW UTXOs), each with different security and economic properties. Linear signature hashing and malleability fixes will only be available to the SW UTXO. Most seriously, there are no enforceable constraints to the growth of the non-SW UTXO. This means that the network (even upgraded nodes) are still vulnerable to transaction malleability and quadratic signature hashing from non-SW outputs that existed before or created after the soft fork.
The lack of enforceability that comes with a soft fork leaves Bitcoin users and developers vulnerable to precisely the type of attacks SW is designed to prevent. While spending non-SW outputs will be comparatively more expensive than SW outputs, this remains a relatively weak disincentive for a motivated attacker.
It is also unclear what proportion of the total number of the legacy UTXO will migrate to SW outputs. Long-term holders of Bitcoin, such as Satoshi Nakamoto (presumed to be in possession of ~1 million Bitcoin), may keep their coins in non-SW outputs (although it would be a significant vote of confidence in SW by Nakamoto if they were to migrate!). This makes future soft or hard forks to Bitcoin more difficult as multiple classes of UTXOs must now be supported to prevent coins from being burned or stolen.
One key concern is that the coexistence of two UTXO types may tempt developers and miners in the future to destroy the non-SW UTXO. Some may view this as an unfounded concern, but the only reason that this is worth mentioning in this article are the comments made by influential individuals associated with Bitcoin Core: Greg Maxwell has postulated that “abandoned UTXO should be forgotten and become unspendable,” and Theymos has claimed “the very-rough consensus is that old coins should be destroyed before they are stolen to prevent disastrous monetary inflation.”
As the security properties of SW outputs are marginally better than non-SW outputs, it may serve as a sufficient rationalization for this type of punitive action.
The existence of two UTXO types with different security and economic properties also deteriorates Bitcoin’s fungibility. Miners and fully validating nodes may decide not to relay, or include in blocks, transactions that spend to one type or the other. While on one hand this is a positive step towards enforceability (i.e. soft enforceability), it is detrimental to unsophisticated Bitcoin users who have funds in old or non-upgraded wallets. Furthermore, it is completely reasonable for projects such as the lightning network to reject forming bidirectional payment channels (i.e. a multisignature P2SH address) using non-SW P2SH outputs due to the possibility of malleability. Fundamentally this means that the face-value of Bitcoin will not be economically treated the same way depending on the type of output it comes from.
It is widely understood in software development that measures which rely on the assumption of users changing their behavior to adopt better security practices are fundamentally doomed to fail; more so when the unpatched vulnerabilities are permitted to persist and grow. An example familiar to most readers would be the introduction and subsequent snail’s pace uptake of HTTPS.
3.3 SW places complex requirements on developers to comply while failing to guarantee any benefits
SW as a soft fork brings with it a mountain of irreversible technical debt, with multiple opportunities for developers to permanently cause the loss of user funds. For example, the creation of P2SH-P2WPKH or P2SH-P2WSH addresses requires the strict use of compressed pubkeys, otherwise funds can be irrevocably lost. Similarly, the use of OP_IF, OP_NOTIF, OP_CHECKSIG, and OP_CHECKMULTISIG must be carefully handled for SW transactions in order to prevent the loss of funds. It is all but certain that some future developers will cause user loss of funds due to an incomplete understanding of the intricacies of SW transaction formats.
In terms of priorities, SW is not a solution to any of the major support ticket issues that are received daily by Bitcoin businesses such as BitPay, Coinbase, Blockchain.info, etc. The activation of SW will not increase the transaction capacity of Bitcoin overnight, but only incrementally as a greater percentage of transactions spend to SW outputs. Moreover, the growing demand for on-chain transactions may very well exceed the one-off capacity increase as demonstrated by the increasing frequency of transaction backlogs.
In contrast to a basic block size increase (BBSI) from a coordinated hard fork, many wallets and SPV clients will immediately benefit from new capacity increases without the need to rewrite their own software as they must do with SW.. With a BBSI, unlike SW, there are no transaction format or signature changes required on the part of Bitcoin-using applications.
Based on previous experience with soft forks in Bitcoin, upgrades tend to roll-out within the ecosystem over some time. At the time of this writing, only 28 out of the 78 business and projects (36%) who have publicly committed to the upgrade are SW-compatible. Any capacity increase that Bitcoin businesses and users of the network desire to ease on-chain fee pressure will unlikely be felt for some time, assuming that transaction volume remains unchanged and does not continue growing. The unpredictability of this capacity increase and the growth of the non-SW UTXO are particularly troubling for Bitcoin businesses from the perspectives of user-growth and security, respectively. Conversely, a BBSI delivers an immediate and predictable capacity increase.
The voluntary nature of SW upgrades is subject to the first-mover game theory problem. With a risky upgrade that moves transaction signatures to a new witness field that is hidden to some nodes, the incentive for the rational actor is to let others take that risk first, while the rational actor sits back, waits, and watches to see if people lose funds or have problems. Moreover, the voluntary SW upgrade also suffers from the free-rider game theory problem. If others upgrade and move their data to the witness field, one can benefit even without upgrading or using SW transactions themselves. These factors further contribute to the unpredictable changes to Bitcoin’s transaction capacity and fees if SW is adopted via a soft fork.
3.4 Economic distortions and price fixing
Segregated Witness as a soft fork alters the economic incentives that regulate access to Bitcoin’s one fundamental good: block-size space. Firstly, it subsidises signature data in large/complex P2WSH transactions (i.e., at ¼ of the cost of transaction/UTXO data). However, the signatures are more expensive to validate than the UTXO, which makes this unjustifiable in terms of computational cost. The discount itself appears to have been determined arbitrarily and not for any scientific or data-backed reasoning.
Secondly, the centralized and top-down planning of one of Bitcoin’s primary economic resources, block space, further disintermediates various market forces from operating without friction. SW as a soft fork is designed to preserve the 1 MB capacity limit for on-chain transactions, which will purposely drive on-chain fees up for all users of Bitcoin. Rising transaction fees, euphemistically called a ‘fee market’, is anything but a market when one side — i.e. supply — is fixed by central economic planners (the developers) who do not pay the costs for Bitcoin’s capacity (the miners). Economic history has long taught us the results of non-market intervention in the supply of goods and services: the costs are externalised to consumers. The adoption of SW as a soft fork creates a bad precedent for further protocol changes that affirm this type of economic planning.
3.5 Soft fork risks
In this section we levy criticisms of soft forks more broadly when they affect the protocol and economic properties of Bitcoin to the extent that SW does. In this case, a soft fork reduces the security of full nodes without the consent of the node operator. The SW soft fork forces node operators either to upgrade, or to unconditionally accept the loss of security by being downgraded to a SPV node.
Non-upgraded nodes further weaken the general security of Bitcoin as a whole through the reduction of the number of fully validating nodes on the network. This is because non-upgraded nodes will only perform the initial check to see if the redeem script hash matches the pubkey script hash of the unspent output. This redeem script may contain an invalid witness program, for P2WSH transactions, that the non-upgraded node doesn’t know how to verify. This node will then blindly relay the invalid transaction across the network.
SW as a soft fork is the opposite of anti-fragile. Even if the community wants the change (i.e., an increase in transaction capacity), soft-forking to achieve these changes means that the miners become the key target of lobbying (and they already are). Soft forks are risky in this context because it becomes relatively easy to change things, which may be desirable if the feature is both minor and widely beneficial. However, it is bad in this case because the users of Bitcoin (i.e. everyone else but the miners) are not given the opportunity to consent or opt-out, despite being affected the most by such a sweeping change. This can be likened to a popular head of state who bends the rules of jurisprudence to bypass slow legal processes to “get things done.” The dangerous precedent of taking legal shortcuts is not of concern the masses until a new, less popular leader takes hold of the reigns, and by then it is too late to reverse. In contrast, activating SW via a hard fork ensures that the entire community, not just the miners, decide on changes made to the protocol. Users who unequivocally disagree with a change being made are given the clear option not to adopt the change — not so with a soft fork.
3.6 Once activated, SW cannot be undone and must remain in Bitcoin codebase forever.
If any critical bugs resulting from SW are discovered down the road, bugs serious enough to contemplate rolling it back, then anyone will be able to spend native SW outputs, leading to a catastrophic loss of funds. ...
...
Conclusion
Segregated Witness is the most radical and irresponsible protocol upgrade Bitcoin has faced in its eight year history. The push for the SW soft fork puts Bitcoin miners in a difficult and unfair position to the extent that they are pressured into enforcing a complicated and contentious change to the Bitcoin protocol, without community consensus or an honest discussion weighing the benefits against the costs. The scale of the code changes are far from trivial — nearly every part of the codebase is affected by SW.
While increasing the transaction capacity of Bitcoin has already been significantly delayed, SW represents an unprofessional and ineffective solution to both transaction malleability and scaling. As a soft fork, SW introduces more technical debt to the protocol and fundamentally fails to achieve its design purpose. As a hard fork, combined with real on-chain scaling, SW can effectively mitigate transaction malleability and quadratic signature hashing. Each of these issues are too important for the future of Bitcoin to gamble on SW as a soft fork and the permanent baggage that comes with it.
As much as the authors of this article desire transaction capacity increases, it is far better to work towards a clean technical solution to malleability and scaling than to further encumber the Bitcoin protocol with permanent technical debt. ...
MORE: https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
submitted by german_bitcoiner to btc [link] [comments]

Checksig: Transparent Bitcoin Custody Bitcoins Value Proposition by Tone Vays Bitcoin's Real Value After Eleven Years- Is This a Pump and Dump Scam? Bitcoin ($BTC) Price Analysis - Bears in Charge? Why Does Bitcoin Have Value? - D-Central

The most popular and trusted block explorer and crypto transaction search engine. This article describes the operation of OP_CHECKSIG in non-segwit scripts. The hash digest for OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, OP_CHECKMULTISIGVERIFY in segwit scripts is calculated differently, as described in BIP 143.. OP_CHECKSIG is script opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack. You’ve thought about it, now it’s time. Create a Wallet. Sign up for the Exchange. Buy Bitcoin in minutes. Checksig and the value of bitcoin Having joined the community only a few months ago, Checksig has continued to grow and make a name for itself. In order to deepen its activity and its projects we asked its founder, Ferdinando Ametrano , to tell us something about them. Explorer Live Data, Charts & Transactions. Buy Bitcoin Trade. Sponsored Content

[index] [23002] [22556] [29613] [12742] [14492] [18687] [23282] [20496] [16065] [10424]

Checksig: Transparent Bitcoin Custody

TechnicalRoundup is sponsored by Bybit (https://twitter.com/Bybit_Official) Visit Bybit: https://bit.ly/2XMxbuJ ----- Technic... Bitcoin Price History in Dollars From 2012 to 2017 (Monthly) - Duration: 2:01. Paddingtonyt 1,883 views. 2:01. 100 Year History Of Silver Prices Proves Its Worth! - Duration: 13:23. If you had invested $200 in Bitcoin in 2009 what would it be worth compared to investing $200 in Amazon, Facebook or Google. If you wanted to buy an Alabama peach with your Bitcoin how would you ... Bitcoin has value because of the faith people place in it as well. The price of Bitcoin fluctuates much faster than most stocks that are traded on the New York Stock Exchange. This is a point of ... The American Bitcoin Academy seeks to bring Education, Trust and Prosperity to the Bitcoin world. Visit www.americanbitcoinacademy.com and see way Bitcoin is...

Flag Counter