Using this method, no -- not in one output anyways.
P2PKH addresses are  a 20-byte hash of the public key so you're limited to 20 bytes for each output.
If you wish to insert data of more than 20 bytes, you'll have to do it with multiple outputs (i.e encode your message in different fake addresses) in the same transaction. For example, see this transaction

However, as Murch says, you'll be bloating the UTXO set by using this method; the public key isn't "valid" but the UTXOs are, so even though you can't spend the outputs of the transaction, miners and nodes still have to keep track of the UTXO because they can't tell the difference.

If you want something better, then use OP_RETURN like advised, more data can be stored (80 bytes vs 20 bytes) and since the ouptut is provably unspendable, it can be pruned from the UTXO set.

Here you go.
To convert a string to hex, use this website.
Make sure the string you're converting to hex is 20 characters (spaces count as characters), so they can be 40 characters (20 bytes) when you convert to hex, which is equivalent to the Hash160 of the public key.
For example if we use as our text we want to insert in the blockchain, we'll use the website above and we get as the hexadecimal.

Next we need to convert the Hash160 above to a bitcoin address. For that we'll use this website
When we paste the code above to the Hash160 field, we get the following bitcoin address:

To get our message into The blockchain, we simply send some bitcoins to the address generated.
Send a minute amount of bitcoins because you can't recover them at all.

So to test this, I sent 600 sats to the address, you can see the Transaction here
If you want to see your message, you have to select "show scripts and Coinbase"
Then look at the output script for the transaction, you'll see Something looks familiar, it's our message in hex: To convert it to string to read what it says, use this website And paste it there.
It gives us back our message

No, Lightning Network transactions are different from transaction batching.
A lightning channel is a multisig address with pre-signed spend transactions that you change everytime you transact over it.
In fact they don't take place on the blockchain at all (only the channel opening and closing do), that's why they are fast.
This is a good FAQ on how the Lightning Network works.

It seems I misunderstood your previous post.
The Lightning Network nodes are local and not on the blockchain so you can't restore backups deterministically. So without a backup you're SOL.
However in the future you could outsource the watching of commitment transactions to a Watchtower so if your peer tries to cheat you even if you're offline or lose your backup, then the Watchtower could post the penalty transaction on your behalf and take a cut of it as fees.
It's still very nascent at this stage though.


Actually in the past, before version 0.3.13.3, there was no keeypool feature and users had to backup after EVERY transaction.
The Keypool feature was introduced in version 0.3.13.3 by Satoshi after a user lost a large amount of bitcoins because he didn't backup after his last transaction so he didn't have access to the private key of his change address.

---

In hindsight, using Keypool, HD,  and mnemonics seem obvious to us. It wasn't obvious then.
On the future when LN has drastically improved, the improvements would seem obvious I'm hindsight too.

Everything is correct so far till step 6.

Bitcoins exist as unspent outputs (UTXOs) which exist on the blockchain.
So when you're sending bitcoin, you're actually transferring Ownership of a certain UTXO(s) to someone else. A person can only claim a UTXO if he satisfies (a) particular condition (s)
When a bitcoin transaction is made, the scriptPubkey specifies the condition to redeem the output of that transaction.
If you're paying to an address, the output of that transaction specifies the recipient and the condition for claiming that transaction, namely providing the public key of the address (addresses are hashes of public keys), and signing the transaction (signature).
So when Coinbase sends you 1BTC, it's transferring possession of the UTXO (s) that make up 1 BTC to your address (actually to the private key of that address, since it's only the person with the private key of that address that can spend it)

No, it doesn't need to.
Coinbase already specified the address in the transaction.
You do not need to be online to receive it. Same with a bank transfer, you do not need to be online to receive money in your bank account. It's always there for you as long as you can prove you're the owner of the account. So a UTXO is always yours as long as you can prove you're the owner.
Answered above.
Exactly, years.
That's what happens when a transaction is made.
When A sends Bitcoins to B, in the transaction A makes it says: Give x amount of bitcoin to B, iff B provides the public key for this address (an address is a hash of a public key and it is impossible to get a public key from an address if the address hasn't made any transactions because it reveals the public key) and B must sign a transaction from that address (to sign a transaction you need the private key, and you can generate a public key from a private key easily)
The full process is this:
Coinbase sends x BTC to you, specifying that for you to spend it you must provide the public key for that address, and must sign a transaction too.
You and you alone in possession of the private key can do that because it is impossible to 1)get a public key from an address, and 2), get a private key from a public key (you reveal your public key whenever you make a transaction to prove the first requirement)
So for you to spend that transaction you must 1) provide your public key, and 2) sign the transaction claiming the UTXO (bitcoin)
It is validated and compared and  if they match then you have spent that UTXO.
The next transaction you make does the same thing: it references the UTXO Coinbase sent you (this is your input for the transaction) and also specifies requirement for the recipient to fulfill before s/he can spend the bitcoin you sent.

The process is for P2PWKH (sending to an address). P2SH is slightly different.
Like I said above you have to prove you control the address by having the private key.
Whoever has the private key can spend the funds -- bitcoin doesn't know or care if you're the "real" owner or not.
There's no "ownership" in bitcoin, just possession.

Any address would do.
Just encode the private key or mnemonic phrase  in the puzzle.

Or if you're using P2SH address, find a way to encode the redeem script in the puzzle, while giving out the private keys (and order), or encode the private keys and give out the redeem script.

The Bitcointalk community loves crypto puzzles so share your puzzle when you're done.

According to the BIP 39 standard, seeds need to be a fixed length of entropy: 128, 160, 192, 224 or 256 bits. That's 12, 15, 18, 21 & 24 words respectively.
So either your seed phrase isn't complete, or it isn't a BIP 39 seed at all.
Your seed needs to be at least 12 words.

"Invalid mnemonic" means that either the words are incomplete, are in the wrong order (the order matters, the last word is a checksum), or one or more of the words isn't in the BIP 39 word list.

---

You still haven't said what wallet created the seed phrase.

Don't.
It's a bad security practice.
What wallet did you create them on?
What error does Ian Coleman's BIP39 tool give you exactly?

Are you sure you're typing them correctly?
The correct syntax is to type them all in small letters with only a space separating each word. No commas, no nothing.

Can you find the words in the BIP 39 word list?

Please ignore the known troll.
Check his post history.

Actually Bitcoin has had lots of bugsin the past, but they have always been patched before they caused any significant problem.

The penalty system is not "controlled by miners and the development team"
You do not even know how it works or want to  learn how it works.
Either you're a persistent troll or an idiot with double-digit IQ.
Either way, you should really stop shitposting.

No CPU or GPU is good enough for Bitcoin mining.
Your mileage may vary for altcoin mining.

Move your topic to the mining section.

This!
Compare the blockchain size of Ethereum and Bitcoin.
Ethereum's dwarfs Bitcoin's even though Bitcoin is at least 5years older.



It is such a problem that Ethereum developers are talking about charging rent to store data on the Ethereum blockchain

OP: Even though the blockchain size is increasing linearly (at least compared to Ethereum's exponential rate), technological advances are improving and prices of storage are falling also, so it's not really a problem.

You can't. That's the beauty of the Lightning Network.
If it's direct then the counterparties in the transaction -- and only they-- can see it because THEY made the transaction.
If it's a routed payment then it's impossible to know the sender of recipient of the transaction because the Lightning Network employs Onion Routing similar to TOR.
Intermediate hops do not know their position in the route, they don't know about other intermediaries apart from their predecessors and successor and they don't know if the predecessor is the original sender or if the successor is the recipient.

Like I said above,channel  state changes re only available to the main counterparties in the transaction -- intermediaries and observers are not privy to this information.
As explained above the lightning network can't have a block explorer to explore all transactions, however, there are lightning Graph explorers that show information and stats about the nodes on the network.
My favourite is http://1ml.com
A lightning network transaction/channel is a smart contract between two people, and each state change (commitment transaction) is a signed bitcoin transaction so it has all the properties of a bitcoin transaction:  the message was created by a known sender (authentication), that the sender cannot deny having sent the message (non-repudiation), and that the message was not altered in transit (integrity).
The final transaction/ channel close transaction is just another bitcoin transaction that updates the balances between the wallets of the participants.
You'll just see a transaction paying 2 addresses different amounts of bitcoin "from" a multisig address.
Whatever took place in the Lightning Network is not visible.

The Pharmacist is sure going to love this!

While it's true that channel states are obviously not deterministic and thus can't be backed up once via a mnemonic seed phrase like bitcoin private keys, the funds in the channel aren't irrevocably lost; the user can always close the channel unilaterally once the CSV timeout  on the transaction has elapsed.
The design of the protocol isn't flawed; broadcasting stale channel states should be punishable or else nothing stops a peer from trying to cheat by broadcasting old channel states.
What ever caused the peer to broadcast an old channel state, be it dishonesty or error, is not the problem of the protocol.
If a user sends bitcoins to an address and the transaction is confirmed it is irreversible. It doesn't matter if the transaction was sent to the wrong address, or the wrong amount.

There should be a better way of storing/preserving old channel states that survives a hard disk crash or similar.
That design could be improved, but then again, Rome wasn't built in a day.
Back in the day, you had to backup Bitcoin-Qt after every transaction.

I hope and believe LN will get there.

Exchanges may not even run Lightning Channels because they won't be able to make it KYC compliant since no node on the network truly knows the true origin or destination of a lightning transaction.
There's already sort of an exchange that supposedly works on the Lightning Network

Fees are very low right now.
Your transaction will get confirmed within 30 minutes or less.
You paid 8 sats/byte meanwhile transactions with 1 sat/byte get confirmed within 5 blocks at most.

Either way I forwarded your transaction ID to Antpool's transaction acceleration service.

Ken Shirriff has an excellent post on Transaction malleability, so start from there

You see the transactions because someone with the private key made transactions with them.
If the watched address is yours and you never made those transactions then your private key has been compromised.

You said you used Barterdex, which requires you to download an app on your system.
Your private key MAY have leaked when you did that
(I'm not familiar at all with Barterdex or the Komodo platform so I can't say for sure that it's the cause)