If it hasn't been mentioned already, I don't think that ip can be banned. @theymos or other admins, if the one posting this thread looks similar then it'll be an ip used by many people (mine will be UK though) and it is definitely dynamically assigned afaik. So even if you ban one its unlikely they'll use it again.

Ahh thanks. I thought you'd forgot so I did tpost one. I'll put one up when you bump your thread (going out now so will lose connectivity where I am).

Don't make a bot on the exchange platform! Well you can but don't give it default values and call it an advanced part of the program both in the spec and the actual program.

Decentralisation is probably something to do with atomic swap smart contracts or timelocking with an extra signed certificate for them to get it (this will make sense when you start to research it).

You could look at how ethereum and waves work, waves has a decentralised trading platform afaik and might be open source.

---

For security you're going to want to look at how the cryptographic work. Most blockchains use elliptic curve cryptography (sec 1): there's a paper on it.

If it goes over your head you could try looking at RSA first as that's a bit easier to understand and more widely covered.

[Back on the more useful stuff, probably got another day of useful and then I might be back to analysing the paper for the rest]

It’s possible to open a channel between the other person and have a third party form a 2-of-3 multisig. If one of the parties in this transaction won’t participate, the channel funds go to the other party as the penalty (presumably rather than all 3 picking a settlement transaction, each pair agree the amounts they are owed by the channel).
This idea is proposed so the third can focus on setting transaction fees to ensure both partys of the channel pay a reasonable amount in fees.
Lightning network fees should be significantly lower than blockchain fees and are generally paid for the locking up of funds when making a transaction
The fees should be almost unnoticeable with the lightning network for its many different parties that can arrange a hop to the next node. This will allow for keeping the lightning network a viable alternative to the bitcoin blockchain for scalability and speed (with its near instant transactions).

What the lightning network aims to solve:
This means that the bitcoin network can remain fast and scalable to deal with high demand, while allowing for this to be done programmatically to ensure ever user can always take their money back If the other party refuses to cooperate or they just want to take their funds back.
When multiple hops are in use, each participant (“hop” node) takes the responsibility of taking the funds to the next, each participant receives a HTLC with a lower time constraint than the last in order to ensure no double spends can occur on anyone and so each participant knows they still can redeem their funds once the payment clears.

Decrementing timelocks:
Taking the example from the paper, Alice wants to send funds to Dave, through Bob and Carol.
Alice checks how many hops it should take to get the transaction to clear and sets her timelock accordingly, for example since there are four hops that can be taken she can set the timelock to 3. Bob and Carol’s timelocks will be a decremented amount of this so:
Alice and Bob make a HTLC of 3 days expiry
Bob and Carod then make a HTLC of 2 days expiry
Carol and Dave then make a HTLC with a 1 days expiry.

Assuming Dave and Carrol cooperate with each other and agree on the value, the HTLC can be overridden with a new commitment transaction instead which could then funnel down to the rest, however R and the HTLC would still be valid until the new Commitment Transaction was fully signed.  None of this gets broadcast back to the chain and all of them can make a new Commitment Transaction (going backwards up the chain) once they receive and/or make a preimage (where necessary).

For each of the HTLC contracts:
    • Locks are only in force for the time limit specified, if a signed preimage is delivered after the time specified it can’t be accepted as the timelock will already be void
    • One party won’t be able to give funds to the next unless they know they are able to receive funds from the last hop as they do (I.e double spends and fake transactions shouldn’t exist on the network) – and thus the decrementing timelock works in a way that the last HTLC takes longer to become invalidated than the current one so you can’t be in a position where this can occur.

If the receiver of the funds were to broadcast the preimage then it may be possible for the other members to take the money for themselves, so it is important that this information is only relaeased to the last person in the hop that has an HTLC contract they need the preimage to make claimable.


If one party refuses to cooperate, their channel gets closed onto the blockchain but it doesn’t affect everyone else in the chain, they’re still able to use their channels but must go back to the previous commitment transaction before the timelock.
However parties also face a timelock when a person becomes unresponsive and have to keep the HTLC open until it expires.

This is a ramble but an interesting one nontheless.
What is a merkel root tree?
[ALT TEXT: This is a diagram of a merkel root for those who can't view images, if you've seen one before no need to see it again]

This is a data structure that works a bit like a binary tree where every node has two child nodes, the difference is that the parten node normally contains a has of the children instead of actual data and if there is only one child node, the other child node for any node is a duplicate of that child (this is explained better in satoshi's whitepaper).


The keys used for dealing with these transactions are made using BIP32.
BIP32 uses a merkle root tree and uses a branch very far down the tree and assigns that to the first “day” of transactions.
The idea for this system is to start with the deepest child and work your way up, each node on the tree stores the master private key, from which can be derived a master public keys and then public keys and addresses.
The master public keys are shared so that both wallets can derive the same keys for building up raw transactions.
Each master private key also stores information for the node(s) below them so if Alice works up the tree every day and gets to day 5 and decides to disclose her key for day 4, the rest of the eksy for day 3,2,1 can be generated however the keys for day 6+ can’t be.

The ability that this data structure/key generation gives is that only a few kilobytes of data needs to be transferred between clients in order for one client to know the rest of the addresses associated with the other client and to invalidate their transactions (through giving access away to their private keys so it makes it useless to publish old commitment transactions).

I said I'm really bad at writing them. Couldn't think of anything better that was 7 syllables... 🤣

You guys pulled out fast
Darkstar needs much more pressure
from haiku lovers

(one well written haiku should equal one spot).... I was reminiscing with a friend but I can't write these!

Did you keep hold of your token? Have you tried restoring a session? How far did you get with everything, have you gone through every step? 1-4

And the others @easter?

[This was a large topic (8+ pages 43-50) feel free to look at the paper if you want to know more, I just got the important stuff, the diagrams may be a helpful supplement – but I’m pushing my 1 page limit as it is]
A similar construction to the bidirectional payment channel should be created in order handle the payment. If Alice and Bob both have 0.5 btc each in their mutual channel and Alice wants to send funds to someone Bob has a connection with:
1.   A new Commitment Transaction is made for the channel with refunds of 0 and 1 and a new Commitment Transaction, with the second output going towards the new channel.
2.   The new commitment transaction made for the new channel pay Alice 0.4btc, Bob 0.5btc and an extra 0.1btc output to Bob’s contact
4 keys are used in this new HTLC, the ones for the old commitment transaction and the ones for the new as well as an additional message R (preimage) which states that the funds can be transferred from alice to bob and to bob’s counterparty. Presumably Bob’s counterparty signs that after he updates their current balance on the commitment transaction and both of them agree.

Before the HTLC runs out, Bob is able to broadcast his delivery transaction to return the 0.1 btc back to Alice and reset both of their balances to 0.5 (this may be done if the other party refuses to sign a commitment or Bob’s client can’t deal with the transaction) – bob doesn’t have to wait on the refund to confirm when he broadcasts one and Alice should have access to her funds immediately.
Alice can also broadcast a return transaction that brings the funds back to her, Alice must wait a predetermined amount of time before this transaction will validate however.

If Bob can produce a preimage R, then this R makes his HTLC execution transaction compliant with the blockchain and he is free to broadcast that beyond this point (as long as he has a preimage). This new transaction produces two RSMCs with two multisigs, the first is only valid after 1000 confirmsations but the second is valid immediately.

HTLC termination off chain requires both cosigners to agree on the new state of the channel. The sender must prove they have preimage R and fulfilled their obligations.
If they can both agree on the new channel state, it’s better to sort the new Commitment Transaction for the old channel off chain (saves fees and block size…) They must also sign breach remedy agreements for the HTLC so that becomes invalidated.
If one party becomes unresponsive, the information they have should be enough to publish what is theirs on the blockchain and refund both members of the channel – submitting their HTLC commitment transaction, initial commitment transaction and delivery transactions.

Order for closing an HTLC
        1. Alice (the sender) signs a new Commitment Transaction and a Revocable Delivery Transaction for bob’s funds in the HTLC and sends it to Bob.
               At this point, Bob is able to broadcast either the new commitment transaction or the HTLC commitment transaction so he can still take his funds back, but once a new commitment transaction is signed out of the HTLC, he will go with that one if he wanted to close the channel).
        2. Bob then signs and sends a Commitment Transaction and the revocable delivery for Alice’s funds in the HTLC.
      Bob’s funds aren’t signed from the HTLC for the revocable delivery but rather the original channel it seems.
        3. Alice signs bob’s revocable delivery and commitment transaction for the new non-htlc channel.

Within the time window (the paper gives an example of a few days but I’m assuming it’s minutes or seconds now):
If the transaction goes though, Bob is able to broadcast R and the commitment transactions to take his money back.
If the time runs out and bob doesn’t do this, Alice is able to broadcast her HTLC Timeout transaction and revocable delivery transaction and the relevant data to the blockchain. She normally has a small amount of time to do this, and may have a similar time (or less) than what Bob had so she must be fast or may risk using the funds in the multisig.

If you have a good enough knowledge you could probably convince a local community centre or school to accept you to do a public talk.

I feel this is something you'd want to travel around with, it's much better than grounding yourself in one place and probably cheaper. You may also be able to do web conferences and seminars and get people to watch/or produce free content online on your own web site.

Thanks for the input! I'll take a look at it again tonight and see what's what. I've been doing a huge amount of page hopping and I wouldn't like to tackle the git repo for bitcoin nodes to check what functions and what doesn't (it'd be nice if they left a flag on bips but they may already do)...

---

As an edit, I've just got through fixing any errors I could find in the first 6 lessons, if you spot anything else please let me know - some smaller things are harder to find, and it's normally harder to find more than one source mentioning it.

Keep your loyalty with Windows 7, it was one of the best... If you have AV that can still support it then you should be fine to keep running ir and not much can go wrong if you don't have large amounts on the wallet (and if you do you can use an spv client or a hardware wallet on another machine/os).

Tor threading is normally used even if you don't have tor enabled afaik also.

It probably is secure enough to push your channel backup to your emails... The 12/24 word seed keys should be used for the signing derived from your mnemonic.

@TL, if you don't want to lose it/want to expand your channels more then you can always transfer the funds to the new wallet.

---

Does my personal text look alright? I can't work out what to call it that'll fie in the length limit.

Maybe the arguments are due to you spending too much time in meta and little in the bitcoin related boards?

I only ever see stuff about arguments in the other subsection and I often avoid it and just stick to the more technical boads...

If you're getting annoyed people are discussing a forum then don't come to the subsection where forum discussion is done!

The posts being deleted looks quite shady, also you're probably better off moving this to meta through the "move topic" link in the bottom left.

The network is designed so that both parties are assured that they have full control over their funds so most funding transactions should never have to broadcast closure information (the clients just know it’s available to them if there are any problems).
Once someone decides to close a channel, they can contact the other party and can sign out the funds from the funding transaction based on the most recent Commitment Transaction. Once this is done, no further payments can be made within the channel and funds will be returned back to the user as soon as the transaction is broadcast (this can be done almost immediately if both parties agree to sign a new transaction – which would be the case for cooperative closure).

Cooperative closures allow both parties to receive funds immediately and also allow for fewer transactions to be published on the blockchain (less data has to be stored).

Hashed Timelock Contract (HTLC)
These are used for linking multiple bidirectional payment channels to create multiple hops for when you want to spend to someone you don’t have a channel directly open with.
HTLC uses nLockTime to ensure that the funds can only be spent after a certain point in time so that one channel can’t spend funds without crediting it to the desired node after them. This transaction data must also be revocable for if the node can’t be used for routing (i.e. it turns malicious).

    1. Bob must be able to sign a random 20 bytes of data on the input of a transaction saying he will allow Alice to claim 0.1 bitcoin after 3 days. (so as to timelock bob’s bitcoins to the same value). [presumably both have to stake 0.1BTC into a contract).
    2. If the three days elapses then the above clause is nullified and the contract becomes nullified and neither is able to settle or claim the funds.
    3. Either party should pay out to the terms stipulated in the contract once they both agree.
    4. If the users don’t agree on how to settle the contract then a penalty is awarded to the user who complied with the terms of the contract first.

HTLCs are marked up in days whereas RSMCs are marked up by blocks (for most computers this isn’t a problem as there are many timeservers and most computers store UTC and convert it for the user whenever they want to see the time – eliminating timezone issues).

This is essentially a way to allow for funds to be sent to the sender to send the funds on within a specific timeframe and if that fails then the sender may take their funds back.

These timestamps are enforced by the blockchain and verification must be possible in all full nodes already to ensure an appropriate timestamp is being suggested for each block (I.e blocktime <= current time). Special IF-ELSE conditions are used in these transactions to ensure they function correctly. (translated example from page 31 of whitepaper shown below):
OP_IF
   OP_HASH160 <HASH160(R)> OP_EQUALVERIFY
   2 <Alice2> <Bob2> OP_CHECKMULTISIG
OP_ELSE
   2 <Alice1> <Bob1> OP_CHECKMULTISIG
OP_ENIF
Essentially:
IF we are past the time given in the TimeLock then The address R gets funded and Alice and Bob take their share of the remaining funds back. If we are still in that time and the transaction is not valid, Bob and Alice take all of their funds back provided they agree on their new Commitment Transaction.

It's going to be different wherever you go and specifics willl be hard to find, are you just travelling inside the EU? Or are you going further. If you're going further there may be issues, most of Europe don't have kyc on cash trades, Finland is probanly an exceptoln.

You running Windows or Linux? Have you updated anything else recently either and do you have an AV?

My nmonic seed words.

Can you backup the app data just to be sure?