5 ms·
What?? I'm not for or against either side, but what you just said is just plain wrong and it looks as if you are the one who has not read either the paper or t
by sboselli 9y ago
What??
I'm not for or against either side, but what you just said is just plain wrong and it looks as if you are the one who has not read either the paper or the forum post. He did not mention payment chains either in the paper or the old original post about block size.
- xorcist 9y agoThere are not "sides" as much as there are countless copies of Bitcoin. There were lots of discussions around applications of Bitcoin at the time. Payment channels were only one of the suggestions, but it was what Satoshi advocated. Why do you think opcodes for lock times were put in there? See my answer below. There is no reason to lash out with misguided accusations when everyone can read the discussions in verbatim.
- kobeya 9y agoThe very first version of bitcoin had payment channels in the code. That's what sequence numbers are for. That's why there are sighash flags and weird rules for blanking sequence numbers. That's why the first version of bitcoin had transaction replacement. It just happens to also be the case that the design Satoshi had for payment channels at that time was horribly broken and left nodes open to DoS attacks. So it was removed by other developers and slowly over time safe versions of the features were added again in the form of BIP68 (sequence number transaction replacement) and BIP141 (segwit).
- Jabanga 9y agoIt did not have payment channel code. There is nothing to indicate that the nLockTime field was originally intended for use in payment channels. There is no source for when the conversation between Satoshi and the developer, in which Satoshi describes payment channel functionality, took place. And large blocks were very much part of Bitcoin's original plan. They were described even before the initial release of the software: http://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html http://www.mail-archive.com/cryptography@metzdowd.com/msg099...
- kobeya 9y agoOk, well I HAVE the early code and it very much does have transaction replacement code using the sequence field.
- keymone 9y agois this the original code - https://github.com/bitcoin/bitcoin/commit/4405b78d6059e536c36974088a8ed4d9f0f29898 https://github.com/bitcoin/bitcoin/commit/4405b78d6059e536c3... ? or can you point to earlier version?
- Jabanga 9y agoIt doesn't have anything that could be argued to be intended for payment channels.
- xorcist 9y agoWhat did you think the purpose of time locked smart contracts was? You can either believe Nakamoto Transactions originated with Satoshi, or you can ask just about anyone who was around at the time. Why do you think there was a scripting language at all? If simple payments was all that was envisioned we wouldn't have needed that. It's strange thing to try to summarize something and have someone question it happened at all. The subtext of this confuses me. This is a public mailing list and most of the people are still around and can answer much better than I can why the design of the opcodes are the way they are. There have been surprisingly many blind alleys in the short life of Bitcoin. Payment channels are what Satoshi advocated, but it was my impression at the time that many others were more interested in things like sidechains and bearer proofs. The scalability of a system where everyone stores everyone else's transactions for all eternity was and still is the first thing people comment on. The second is the feasibility of everyday payments when the recommended confirmation time is up to an hour, best case. That's the reason people took interest in these proposals, even at a time when there was no economic pressure to do so, as transactions were completely free. There's was no "original plan" as much as there were discussions. That doesn't mean Satoshi didn't have opinions. If your impression of the block size is shaped by the carnival mirror that is Reddit, it might be interesting to look at the reasoning why this limit was kept in place. But none of that matters in practice right now, because there is overwhelming consensus to double the block size (or quadruple, thinking adversarially) in a backwards compatible way and this will be active in a matter of weeks.