Thank you! :)

Thank you.

Thanks Simon, got a few more videos planned :)

Thanks Pierre.

Thank you, means a lot.

Thank you.

Got it, thank you very much! :)

The pleasure is all mine, thanks for being so kind!

Thank you.

My pleasure, thank you.

I can literally say the same thing even now. Great job bro, What is your Twitter handle?

Will do, thank you!

No problem, glad you like it!

My pleasure. Thank you for the kind words.

My pleasure, thank you :)

Thank you

Thank you

Thanks! And sure, transactions would be a fine place to begin. Start with whatever your audience finds most interesting and relevant. Personally I think you can break Bitcoin up in to the following main parts: * Networking (The Bitcoin Network) * Mining * Blockchain * Transactions * Script * Keys / Addresses I usually start with networking, because I feel that's the big picture part, and gives you a "top down" approach. Other books I've read seem to start with Keys/Addresses for a more "ground up" approach. But I think you could start anywhere really. As long as you have a reason and a logical flow that's all that matters.

@@learnmeabitcoin gotcha, thank you 🙏

I intend to at some point, thanks for the reminder.

Thank you, I appreciate it. And that's an interesting question... I haven't given it much thought before. The first thing I do is understand how it works. The better I understand something, the easier it is to explain. I spend a lot of time coding things from scratch and playing with data. For example, for this video I decoded existing transactions, then coded my own transactions from scratch and sent them in to the network to see if they worked. I like figuring out how things work. When it comes to explaining things, I think "If I completely forgot about this topic, what would be the quickest way for me to relearn it again?", then I try to achieve that. It's a lot easier if you break things down in to sections. I also try to avoid looking at existing explanations of the same topic so I can build up my own picture in my head. The main sources I use are pencil and paper. Ultimately I just like the challenge of taking something that's thought to be complex and explaining it in really simple terms so everyone can understand it. I don't think many topics are truly difficult to understand, it's just that some topics are difficult to explain. But you can explain anything if you break it down enough. Thanks for asking.

Hi Hari, I'm not sure I fully understand your question, but I'll give some sort of answer anyway. I'm pointing to an output from a previous transaction, and that's what I'm using as the input the transaction I'm constructing. So someone has sent us some bitcoins in a previous transaction (the output), and we're going to unlock it this new transaction (as an input). To unlock this input for use in the current transaction, we need to create a signature using the private key. But in the process of creating this signature, we also need to grab the locking script that was originally placed on the output (this is just how the signing process works). Does this help answer your question? Greg.

Thanks Al. I learn't a lot by making my own blockchain explorer, as I had to figure out what all the data meant so that I could display it on a webpage. As far as learning resources go, I found en.bitcoin.it/wiki and the bitcoin.stackexchange.com to be the most helpful. But overall, trying to build something is what helps me to learn the most.

Sure. I'd like to cover all the remaining basics of Bitcoin first (Networking, Blockchain), but after that I'll move on to more recent changes like SegWit and lightning. Thanks for the suggestions.

Yes that's correct, it's the hash160(public key) and not the raw public key. Thank you.

In general, an address is just an encoding of a public key that's easier to share. So whilst we pass around addresses when we want to send each other bitcoin, it's actually the underlying public key that gets put inside transaction data. In this particular locking script for example, the address contains the hash of a public key (to make it shorter), and this is what gets put inside the locking script. When we come to unlock these bitcoins for spending, we provide the original public key, and this is compared with the hashed version in the lock to make sure they match, before going on to perform the signature validation against the public key as normal. You can see how this mechanism works here: learnmeabitcoin.com/technical/p2pkh It looks a bit complex at first, but in general, addresses are what we pass around, but the original public keys are used inside transaction data. Does that make sense?

@@learnmeabitcoin make sensé but i learned in Mastering Bitcoin that an adresse was a double hash from a public Key. ( Sha 256 and then RIPEMD 160 hash function) thanks you for your vidéos by the way they are really cool. I think i am wrong because i don't know much i will see the video with the link

@@pierrehavard3237 Yes that's correct. Public Key -> SHA-256 -> RIPEMD-160 -> Base58 Encode (with checksum) = Address Then when you give someone that address, they Base58 Decode it and put the hashed public key inside the locking script on top of the bitcoins they're sending you.

I don't run classes or anything on the regular; these videos were mainly one-off explanations with Neville (sorry). If it's any help, feel free to ask any questions in the comments and I'll do my best to answer them.

Nothing on Ethereum I'm afraid.

If you tried to use an output (that has already been spent) as an input in a new transaction, then every node you send this new transaction to will reject it. They will not accept it in to their memory pool, nor will they relay it to other nodes. A full node keeps a copy of every bitcoin transaction ever made, so they know which outputs have been spent or not. My "greying out" was just to indicate that nodes would reject any transaction that tried to spend an output again.

​@@learnmeabitcoin My bad of not asking a clear question... My question is more like how does it 'get rejected' ? Does it check against each transaction in the whole chain, or there is some other magic?

@@luyangdu1036 No problem, sorry I didn't explain more thoroughly. Bitcoin actually keeps track of every unspent output in a separate database (called the "chainstate" database). This makes it faster to lookup outputs during transaction validation (as opposed to scanning the entire blockchain for them). So if an input in a transaction cannot be found in the chainstate database, the transaction will be rejected.

All fixed. There was a problem with the host. Thank you for letting me know.

@@learnmeabitcoin thanks sir, the explanation so good for my assignment

@@vuongngo8228 My pleasure, I'm glad I could help. Good luck with your assignment.

In the early days of bitcoin, a wallet would run on top of a node. These days you can run a lightweight wallet (without running your own node), and that wallet can just connect to someone else's node. The easiest method to get the balance of an address would be to use a blockchain explorer. Other than that, to get the balance of an address you could sum the values of unspent outputs located at each address in the chainstate database (the database containing all the unspent outputs in your bitcoin node).

You make a good point. But how would you keep track of how much each person owned? The benefit of using UTXOs is that you only need to keep track of those UTXOs. So whilst it might seem awkward at first to create change outputs, it makes the transaction system more efficient. There may be a better method, but you have to figure out how it would work.

Having a student helps me to present the information. I realize that it may interrupt with your own personal flow of understanding whilst watching, but without this student I wouldn't have been able to make these videos. Thanks for the kind words about the overall video though nonetheless.

i disagree, the student was helpful

Actually let me reformulate my earlier comment: you are a negative asshole