Bitcoin Forum
May 17, 2024, 01:41:38 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Development & Technical Discussion / Will we ever have fungibility enhanced TXs that are cheaper than normal TXs ? on: May 23, 2018, 04:12:12 PM
By fungibility enhanced I'm thinking of tools like coin-join etc..

It seems to me that most people don't care for privacy because "they got nothing to hide"...(or so they think)

But they are all interested in saving money...

So for these tools to actually work with a large anonymity set, wouldn't it be great if they were actually cheaper to use than normal transactions..?

I mean the total amount of fees paid by 100 people in a coin-join should ideally be cheaper than the total amount of fees paid by the same 100 people if they are just sending normal transactions...

Is there any hopes for this to become reality...?

Thanks for reading!
2  Bitcoin / Development & Technical Discussion / "Money is a social construct and that’s why you should run a bitcoin full-node" on: November 03, 2017, 03:26:00 PM
Please check out my new post on Medium.

"Money is a social construct and that’s why you should run a bitcoin full-node"

All feedback is highly appreciated.
Thank you!

Link:
https://medium.com/@AudunGulbrands1/money-is-a-social-construct-and-thats-why-you-should-run-a-bitcoin-full-node-ea0330cb69a5
3  Bitcoin / Development & Technical Discussion / Fork-Attacks on bitcoin like Bcash and B2X might become infeasible after halving on: August 26, 2017, 08:35:30 AM
Please share your thoughts around this claim:

"Fork-Attacks on bitcoin like Bcash and B2X might become infeasible after next halving; due to the value of mining reward becoming Fee>NewCoin"

You can Fork the block reward (New-Coins)
But all the economic fee-generating-activity stays on original chain
Miners must follow the User rather than New-Coin

I haven't seen any discussion around this topic, so I'm curious if I'm missing something..
4  Bitcoin / Bitcoin Discussion / An open letter to Canaan and to all UASF-supporters on: July 17, 2017, 07:08:15 PM
Please check out my open letter on Medium:
 https://medium.com/@AudunGulbrands1/an-open-letter-to-canaan-and-to-all-uasf-supporters-b954be0b3f6a

Or just read the copied text below:


Dear Canaan

Thank you for creating a solid product, and thank you for the fast delivery!

My AvalonMiner has been working flawlessly since the day I turned it on.

As a producer of top notch mining equipment, it is clear that this moment in time holds a unique opportunity for you…

Please consider giving your support for BIP148.

From a pure PR and marketing perspective, your support for BIP148 is likely to be a very good business decision.

You would immediately gain enormous attention and make yourself tremendously popular amongst a large part of the bitcoin community.

In addition to purchasing your products, many bitcoiners will begin to actively promote your brand.

Everyone in the world of bitcoin will know your name, and you will forever be regarded as heroes for helping the activation of SegWit.


Dear UASF supporters

Please help me prove that the above is true.

I urge everyone of you to actively support and promote Canaan, starting today.

Give Canaan a taste of what is to come if they choose to support BIP148.

Make it clear that you will strongly support and promote Canaan if they support BIP148.

Let’s give them a solid economic incentive to join our side.

We can do this by purchasing the AvalonMiner, and clearly state that we will use it to support BIP148/UASF/SegWit.

If you don’t have the opportunity to acquire your own AvalonMiner, you can still help by actively promoting Canaan on social media.

Inform everyone in your community that Canaan can make fast delivery of top quality mining equipment and make it clear that Canaan is your favorite ASIC producer.


This is truly a Win-Win!

Let’s make SegWit happen!

5  Bitcoin / Development & Technical Discussion / What will trigger a reorg after BIP148 split? "longest chain" or "most work" ? on: May 30, 2017, 05:40:16 PM
Question:
Assuming a split occurs after the BIP148 UASF..
What condition will trigger a reorg of the non-segwit-chain?
Is it *longest chain* or is it *most work chain* ?
6  Bitcoin / Development & Technical Discussion / How to install and run the UASF enforcing code(BIP148 SegWit) Guide for dummies on: May 18, 2017, 03:33:51 PM
Until recently I was not aware that this code is already available.
I wanted to signal my support for a UASF so I asked for help on r/bitcoin..

The instructions I received was very helpful!

Check out the links below if you are interesting in running the UASF code...

Can someone please provide the following: "How to signal UASF, a guide for dummies" ?
https://www.reddit.com/r/Bitcoin/comments/6bim3z/can_someone_please_provide_the_following_how_to/dhnbzg1/

By request: How to signal UASF, a guide for dummies:
https://www.reddit.com/r/Bitcoin/comments/6bkk3c/by_request_how_to_signal_uasf_a_guide_for_dummies/

7  Bitcoin / Development & Technical Discussion / Suggestion for the bitcoin Core GUI: QR-code for easy connection to trusted node on: May 10, 2017, 05:05:37 PM
Some wallets, for instance the Samourai wallet; offer the ability to connect to a trusted node (your own)
Wouldn't it be great if this could be done by simply scanning a qr-code..

I’m sure that if this functionality was built directly into the Core GUI, then most of the wallet providers would adapt and make it super easy to pair your node and your phone.

So what do you think?
Is this possible / desirable?
8  Bitcoin / Development & Technical Discussion / How is it possible to measure the amount of nodes that are just "listening" ? on: April 05, 2017, 12:34:57 PM
This pie chart keeps on popping up everywhere:
http://luke.dashjr.org/programs/bitcoin/files/charts/software.html

It shows that the actual number of bitcoin core nodes is more that 67 000...

A very different number is shown at:
https://bitnodes.21.co/

My understanding is that the chart by Luke is also showing nodes that do not accept incoming connections...
In other words: Nodes that are only listening and do not forward transactions and blocks.

But how is it possible to measure the number of such nodes?
Can someone please explain..?
9  Bitcoin / Development & Technical Discussion / Q: If BU hard fork happens; Can an empty block be made valid on both chains? on: March 29, 2017, 08:42:19 PM
Question:
If BU hard fork happens; Can empty blocks be made valid on both chains at the same time?
10  Bitcoin / Development & Technical Discussion / Is it really fair to claim that a LN-Tx is the same as a normal bitcoin Tx? on: March 18, 2017, 12:51:05 PM
I recently made a post r/bitcoin (also posted the same here on Bitcointalk) with the following title:

A Lightning Tx *IS* a bitcoin Tx, and here's why
Link: https://www.reddit.com/r/Bitcoin/comments/5xoijr/a_lightning_tx_is_a_bitcoin_tx_and_heres_why/

After this post I got some valid criticism from /u/jratcliff63367 for not highlighting the fact that a Lightning Tx is a zero-conformation Tx.

The source of my content was my own Lightning FAQ that I have published on Medium.
Link: https://medium.com/@AudunGulbrands1/lightning-faq-67bd2b957d70#.p1nql0g2b

To address the criticism from /u/jratcliff63367 I have now added a new question to my Lightning FAQ.

Please check it out below:
Feedback is appreciated as always!

 
Q 14.1:
A standard bitcoin Tx is dependent on confirmations in the blockchain...
So, is it really fair to claim that a Lightning Tx is the same as a normal bitcoin Tx?

This is a valid point, they are not the same...
A Lightning Tx is a zero-confirmation Tx. But if it is broadcasted to the bitcoin network; it will be just as valid as any “on-chain” zero-confirmation Tx.
Both types of Tx will eventually be mined into the bitcoin blockchain if they pay a sufficient fee.

However, a LN-Tx has a different security model that makes it much more reliable when compared to a standard zero-confirmation Tx.

A Lightning Tx is only indirectly secured by Proof of Work. This is due to fact that a Lightning Network will be completely dependent on the underlying bitcoin network (see Q12)

Within an open Lightning channel; there is a different set of game-theoretical mechanisms that provide a different type of security model.

Lightning will extend the capabilities of bitcoin without the need for a trusted third party.
But the tradeoff is that you must monitor the bitcoin network by the operation of a full-node.

This monitoring can be outsourced, but in that case you must trust an external server to actually do its job. Your money will still not be routed through this server. The only role of the server is to monitor the bitcoin network, and to broadcast a so-called Penalty Transaction when necessary.

Note that the use of this service is an option, in case you don't want to run your own full-node.
It will not be possible for this third party to steal money from a Lightning channel.

Also note that the LN is intended as a platform for low-value-transfer (sub $100)

All LN transactions are multi-signature and both participants in a channel must sign for a Tx to become valid. A traditional double-spending attack is therefore made extremely difficult.
However, there is a risk that someone can broadcast an obsolete Lightning Tx to the bitcoin network.
An obsolete Lightning Tx is a Tx that does not represent the latest state of its channel.

The above mentioned risk is the reason that you (or a service that you trust) must operate a “Watcher Node”.
This node will monitor all the transactions that are broadcasted to the bitcoin network.

If your Watcher Node discovers an obsolete Tx; it will (as a countermeasure) broadcast a “Penalty Transaction”
The Penalty Transaction gives you the power to confiscate all the money within your channel (including the money that belongs to your counterpart) 
However, a penalty Tx can only become valid after the discovery of a broadcasted obsolete Tx.

Your ability to broadcast a Penalty Transaction makes it very risky for your counterpart to broadcast an obsolete Tx.

Another security/privacy feature, is that all Lightning Tx will be end-to-end encrypted between the participants.

Conclusion:
The security model of a Lightning Tx is different from the security model of traditional bitcoin Tx.
A Lightning Tx will still be regarded as a valid bitcoin Tx if broadcasted to the bitcoin network.

However;
A Lightning Tx will not be publicly broadcasted as long as the channel stays open.
It will only be exchanged between the participants in a channel, and they will store the Tx locally.

We can therefore define a Lightning-Tx as:
A Non-Broadcasted-Zero-Confirmation-Bitcoin-Tx with some additional Security-Mechanisms.
11  Bitcoin / Development & Technical Discussion / A Lightning Tx *IS* a bitcoin Tx, and here's why: on: March 05, 2017, 07:19:55 PM
Question:
You say that the Lightning Network is using real bitcoin transactions…
How can it be a real bitcoin transaction if it’s not recorded on the blockchain?

Short Answer:

To understand this, we first need to understand what a bitcoin transaction really is…
The fact is; That there are no “coins” in Bitcoin…
There are only signed messages and updates to the blockchain.

So let’s say that Alice is sending 1 bitcoin to Bob…
We call this a peer-to-peer transaction due to the fact that the ownership of value is transferred directly from Alice to Bob.
But Bob does not actually receive a “digital coin” from Alice.

The thing that in reality is happening; is that all the nodes in the network will update their local copy of the public ledger.
The public ledger is updated so that; the “coin” that was before registered in an address controlled by Alice, is now instead registered in an address controlled by Bob.

Long Answer:

The bitcoin transaction that Alice is sending to Bob, is in reality just a signed message that Alice is broadcasting to everybody.
The message is not only received by Bob, but it is broadcasted to all the nodes in the network.
At the time of writing there are more than 5400 so called “full nodes” in the bitcoin network.

The following steps illustrates the process that takes place when Alice is sending a bitcoin transaction to Bob:

1. When Alice is broadcasting her signed message (= bitcoin transaction), it will be picked up by some of the full nodes in the network.

2. These nodes will independently validate the message (transaction) in accordance with the consensus rules. If the nodes find the message to be valid; they will broadcast the message again so that it can be picked up by other nodes on the network.

3. Some other nodes on the network will pick up the message, and this process continues until all 5400 nodes have independently validated and re-broadcasted the message (transaction)

4. At some point a miner will succeed in constructing a valid block that includes the message (transaction) from Alice. To make this happen the miner must bear the cost of an enormous amount of electricity.

5. The miner will now broadcast this newly found block. The new block will be picked up by some of the full nodes. The nodes will independently validate the block and all its content.
By doing this they are also validating the message (transaction) from Alice for a second time.
If the nodes find the block to be valid (in accordance with the consensus rules) they will broadcast the block again so that other nodes also can receive the block.

6. Other nodes will pick up the block, validate and broadcast.
This process continues until all the nodes in the network have independently validated the block and thereby also validated the message (transaction) from Alice for a second time.
The steps above illustrate that a normal bitcoin transaction actually involves everyone on the network.
The message is independently validated two times by 5400 nodes (= 10 800 validations)

Despite this, we are still calling it a “peer-to-peer transaction” because the actual ownership of value is transferred directly from Alice to Bob*
(*But everyone still needs to help by updating their local copy of the ledger)

Conclusion:
A bitcoin transaction is just a signed message.

So let’s say that Alice wants to send 1 bitcoin to Bob within a Lightning Channel:

Alice is storing some of her money in a “2 of 2” multi-signature address.

Alice and Bob will both sign a message that transfers the ownership of 1 bitcoin from Alice to Bob.

This message is a valid bitcoin transaction, but it is not broadcasted to the bitcoin network.
Instead Alice and Bob both store the transaction (message) locally.

From Bob’s point of view, this “double-signed message” has a monetary value of 1 bitcoin.
The monetary value of 1 bitcoin comes from the fact that Bob can spend this money on-chain at any time; by simply broadcasting the message to the bitcoin network.

Bitcoin transaction = Signed message = Lightning transaction

The purpose of any monetary transaction is to change the ownership of value.

In the bitcoin network we change the ownership of value by the use of signed messages.

A Lightning transaction is a double-signed message.
This double-signed message is therefore a real bitcoin transaction.


For more FAQs on Lightning please visit:
https://medium.com/@AudunGulbrands1/lightning-faq-67bd2b957d70#.pjgghlggv
12  Bitcoin / Bitcoin Discussion / How do we know that the CIA didn't get to Satoshi? on: March 04, 2017, 04:17:05 PM
Question:
We all know that Satoshi disappeared after Gavin talked to the CIA...

It is mostly assumed (I think) that Satoshi left the project voluntarily..

But how do we know that the CIA didn't get to him first?

Is it not plausible that the CIA was successful in tracking him down?

Disclaimer:
I’ve been into bitcoin for about 3 years now, but I haven't used much time on this particular topic. I’m probably just missing some pieces of the puzzle…

Could somebody please fill me in on the information that I’m missing?
13  Bitcoin / Development & Technical Discussion / The Bitcoin Balance of Power Poster on: February 26, 2017, 04:40:55 PM
Please take a look at my Bitcoin Balance of Power Poster:

https://medium.com/@AudunGulbrands1/the-bitcoin-balance-of-power-poster-91271ab31b86#.nv1zoeqmp
14  Bitcoin / Development & Technical Discussion / Emergency soft fork to add an additional difficulty adjustment cycle (?) on: February 23, 2017, 04:18:26 PM
I’m imagining this concept as an emergency soft fork in the case of a large and sudden drop in the network hash-power.

It’s my understanding that changing the 2016 block difficulty cycle would require a hard fork (since this is a change of a current consensus-rule)

But is there anything stopping bitcoin form adding an additional adjustment cycle with a soft fork?

The current cycle would not be changed, but an additional independent cycle would be added in between.

Both cycles would be 2016 blocks but they would be out of sync so that they come into effect every other time.

In other words; the difficulty would be adjusted every 1008 blocks.

Can anyone tell me if this is possible?
15  Bitcoin / Development & Technical Discussion / The Balance of Power in the bitcoin ecosystem. Feedback appreciated! on: February 22, 2017, 08:48:48 PM
Introduction:

Miners are the rulers of Bitcoin...
At least, this is what people seem to believe..
After all, miners are the ones who create our beloved magic money…

But what happens if, let’s say 75%, of the miners (by hash-power) decides to change the rules of the protocol?

It turns out that miners are not the sole decision makers in bitcoin.

...There is a certain Balance of Power in the ecosystem…

In this post I will focus on the following participants:

Miners (including Hashers and Pool-operators)
Developers
Merchants
Users (including HODLers and traders)
Exchanges
Node Operators
Wallet providers

This balance of power becomes particularly interesting in the event of a hard fork.

As we have learned from Ethereum;
A hard fork that is not supported by everyone; can result a network split.
Effectively creating two different blockchains / networks with two different coins.

This can also be categorized as a “Coin-Split”
(the total amount of units will double)

Both coins are likely to have its own supporters, and both sides are likely to claim to be
“the real bitcoin”



Miners:
 
(including Hashers and Pool-operators)

Miners are thermodynamically securing the network with proof of work.
They are rewarded with new coins in addition to transaction fees. But high operational costs are forcing the miners to sell off the majority of this reward.
 
Miners produce blocks that are mathematically linked in a blockchain.
These blocks contain transactions between the bitcoin users.
The blockchain represents the history of all transactions.

Miners are on the supply side in the market, and are therefore putting downward pressure on the price of bitcoin due to inflation.

Pool-operators construct blocks.
Hashers are payed by Pool-operators to perform PoW on these blocks.

Hashers can leave or join any pool at any time.
A misbehaving Pool-operator risk that Hashers will leave the pool.

Let’s say that a miner successfully finds block X:
The miner will be rewarded with newly created bitcoin in addition to all transaction fees that are included in block X.
However, this money does not become spendable until the blockchain have been extended with an additional 100 more blocks that must be build on top of block X.

If other miners don’t agree that block X is valid, then they will reject the block by not building on top of it.
 
But what if a majority, let’s say 75% of miners (by hash power) have decided to change the existing consensus rules?
They may now see block X as valid, even if the remaining minority (25%) of miners disagree.
 
The minority miners (the ones who does not want to change the rules) are only going to build on top of what they see as the “most work *VALID* chain”
A new and otherwise valid block, will also become invalid (in the eyes of this minority) if it is build on top of block X.

This is where the blockchain will split into two different chains / networks.


Developers:

Developers write the code that makes bitcoin work.
New code only serve as suggestions for improvements.   
Developers cannot force anyone to run new code.

Different types of suggestions are:

Soft Forks:
Suggestions to add new consensus rules.

Hard Forks:
Suggestions to remove (or replace) existing consensus rules.

Changes that do not affect consensus:
Suggestions to add functionality that will effect how the network handles transactions that are not yet mined into a block (transactions that are held in the mem-pool while waiting for a confirmation)
Replace By Fee (RBF) and Child Pays For Parent (CPFP) are examples of this kind.


Merchants:

Are amplifying the perception (amongst users) that bitcoin is valuable. They do this by accepting bitcoin as payment for goods and services.

In the event of a coin-split;
The different merchants must decide whether to accept both coins as payment, or to only accept the coin that he/she like the most.


Users
(including HODLers and traders):

Users give bitcoin its value by;
A) Perceiving it as money, and using it as money.
B) Being willing to exchange their hard earned fiat money for the return of bitcoin. 
C) Acting (for the most part) as the “demand side” in the market, and are therefore putting upwards pressure on the price of bitcoin.
D) Ultimately decides what the value of bitcoin should be, as a product of how much fiat money they are willing to pay per bitcoin.
E) Having confidence that bitcoin will continue to be a good store of value.

If other participants act against the interest of users:
Users have the power to strike back on everyone in the ecosystem; simply by loosing confidence in bitcoin as money.
Loss of confidence by users will put downward pressure on the price of bitcoin, and therefore directly harm the profitability of miners.   

In the event of a 75% Hard Fork:
Users will now suddenly own 2X the amount of units/coins. An equal amount of coins will be held on each side of the fork.

Let’s distinguish between the two coins by calling them b1 and b2:

Users will collectively decide the value of b1 and b2. 

They can choose to:
Save both b1 and b2
Sell both b1 and b2
Sell b1 and save b2
Sell b2 and save b1

Selling will put downward pressure on the price of the coin being sold.
Buying will put upward pressure on the price of the coin being bought.

Users will establish an exchange rate between the two different coins. This means that users can buy b1 with b2, and vice versa.

Users are likely to first spend the coin they perceive as least valuable. And they are likely to save the coin they perceive as being the best “store of value”

Ultimately, users are going to give more value to one side of the fork compared to the other.

These actions made by users, will directly affect the incentive structures of miners.
As the coin with the highest market value will be more profitable to mine.
Economically rational miners will migrate to the coin with the highest value.

Theoretically there may be variations during time on which of the coins (b1 or b2) that holds the highest market value.


Exchanges:

Provide platforms for price discovery where people can buy and sell bitcoin.
In the event of a coin-split an exchange can decide whether or not to allow trading of both coin-types, or to only allow trading of the coin they like the most.
The latter may be risky, since users might be able to sue the exchange. Many users hold coins on exchanges, and this users are likely to demand access to both types of their coins.

Despite the risk of lawsuit, an exchange could technically just confiscating one type of coin, while claiming that this coin is a “fake bitcoin”
They could then choose to dump the coin into the market, thereby crashing the price of the coin they don't like.

Some exchanges may have written into their “terms and conditions” that they can decide what coin its users can access.

There may also be some delay before exchanges can offer the new coin after a coin split. Since the exchanges must adapt their infrastructure to allow trading of a new coin.

When both types of coin are traded on the same exchange, this will quickly result in an exchange rate between the two different coins.


Node Operators:

Nodes are independently validating transactions and blocks in accordance with the current consensus rules.
When a node considers a block to be valid, it will forward the block to other nodes, and the other nodes will repeat the same behavior.   
Nodes can be seen as accountants who validate the transactions created by users and the blocks constructed by miners.
 
Node Operators may download new software if they want to support a change of the current rules
(hard fork)

Nodes that do not want support a hard fork; will simply ignore all blocks that do not comply to its current ruleset. 

Even if these blocks represents the “most work chain” they will still be ignored (seen as invalid) by all nodes who have not download the software that constitutes the rule-change.
Wallet providers

Let’s say that a hard fork leads to a permanent coin-split (similar to ETH/ETC)…
Users will now own coins on both sides of the fork (on both blockchains / both networks)

Users are in need of new software that can handle the two different coins.

Wallet providers decides if they want to develop the needed software.

Wallet providers also decide how they want to display the two different coins in the a wallet.
Depending on which coin they like best, they may decide to display the coins as primary and secondary.
This may influence the perception among some users.

Users who fail to upgrade their wallet-software are likely to loose money.
This is because they lack the tool to handle both sides of the fork (both coins)
When spending money; the transactions are likely to be valid on both sides, so the risk is to loose money on the opposite side of the fork.


FINAL NOTE TO READER:
Thank you for reading!
I’m hoping for feedback to improve this post.
Please tell me if I missed something or got something wrong..
The final product will be posted on Medium.
This is the same technique that I used when I was working on my Lightning FAQ. The final result of that project may be found here: https://medium.com/@AudunGulbrands1
16  Bitcoin / Development & Technical Discussion / Have a question regarding the combination of Lightning, Schnorr and CoinJoin… on: December 25, 2016, 01:08:41 PM
I have been working hard to understand how Lightning works..
With great help from r/bitcoin and Bitcointalk I have put together a Lightning FAQ:

The final result of my work can be found here:
https://medium.com/@AudunGulbrands1/lightning-faq-67bd2b957d70#.8biw0wadf

However, some people have pointed out to me; that it may become expensive to close a Lightning channel, since this will require an on-chain transaction.

I just read the following article in Bitcoin Magazine:
“The Power of Schnorr: The Signature Algorithm to Increase Bitcoin's Scale and Privacy”
https://bitcoinmagazine.com/articles/the-power-of-schnorr-the-signature-algorithm-to-increase-bitcoin-s-scale-and-privacy-1460642496

To summarize;
My understanding of Schnorr and CoinJoin is the following:

Schnorr will allow several signatures to be aggregated into a single, new signature.

Many inputs normally means many signatures, but Schnorr will require only one combined signature to represent all these different signatures.
This means that only one signature must be included in a transaction.

CoinJoin allows different users to combine all their transactions into a single transaction.

Schnorr can enable all participants in a CoinJoin transaction to not only combine their transactions, but to also combine their signatures.


So my question is:

Can Schnorr and CoinJoin be built into Lightning in such a way that several channels can be closed with just one transaction?

So to reduce the cost of closing by having many channels share the cost of just one transaction?
17  Bitcoin / Development & Technical Discussion / Have improved my Lightning FAQ. Added more Qs and As. Submitted to GitHub on: December 19, 2016, 06:04:10 PM
Below you will find a largely improved version of my Lightning FAQ.
Several new questions and answers added.

The FAQ has also been made available on GitHub:
https://github.com/norgesbitcoinforening/lightning-faq

All feedback is still greatly appreciated! 


Q 1:
What is the Lightning Network?

A:
The Lightning Network is currently under development. It will become a decentralized network that enables instant off-chain transfer of the ownership bitcoin, without the need of a trusted third party.
The system utilizes bidirectional payment channels that consist of multi-signature addresses.
One on-chain transaction is needed to open a channel and another on-chain transaction can close the channel.
Once a channel is open, value can be transferred instantly between counterparts, who are exchanging real bitcoin transactions, but without broadcasting them to the bitcoin network.
New transactions will replace previous transactions and the counterparts will store everything locally as long as the channel stays open.


Q 2:
Is the Lightning Network open source?

A:
Yes, Lightning is open source. Anyone can review the code, just in the same way as the bitcoin code.


Q 3:
Who owns and controls the Lightning Network?

A:
Similar to the bitcoin network, no one will ever own or control the Lightning Network.
The code is open source and free for anyone to download and review.
Anyone can run a node and be part of the network.


Q 4:
Who are the inventors of the Lightning Network?

A:
Joseph Poon and Thaddeus Dryja wrote The Lightning white paper.
Lightning is an open source project so anyone is free to contribute with code.
There are currently 5 independent implementations under development:

Blockstream's C lightning:
Blockstream currently have two employees who are dedicated to Lightning development.

Blockchain’s Thunder network

ACINQ have successfully implemented Bitfury's Flare routing algorithm into Eclair, and tested it on a live network of 2500 servers

Amiko Pay

KimDotCom's BitCache lightning network (confirmation needed, I’m not sure about this one)


Q 5:
Does the Lightning Network have its own “Lightning coins”?

A:
No, that’s not how it works.
A Lightning Network will be using real bitcoin transactions with actual bitcoins in them


Q 6:
Is the Lightning Network dependent on consensus to be implemented?

A:
No, a Lightning Network builds an additional layer on top of the bitcoin network.
Therefore it is not dependent on consensus in the bitcoin network itself.


Q 7:
Will there be any form of custodian risk in a Lightning Network?
Do I need to trust anyone to hold my money on my behalf?

A:
No, this system is not based on trust; you remain in full control of your money.
If anything goes wrong you simply broadcast the latest state of your channel as a normal
on-chain bitcoin transaction.
All your money will be returned to your address, and it will be recorded on the blockchain as a normal on-chain bitcoin transaction.


Q 8:
I’ve heard that Lightning transactions is happening “off-chain”...Does that mean that my bitcoins will be removed from the blockchain?

A:
No, your coins will never leave the blockchain.
Instead your coins will be held in a multi-signature address as long as your channel stays open.
“Off-chain” is not a perfect term, but it is used due to the fact that the transfer of ownership is no longer reflected on the blockchain.


Q 9:
I’ve heard that the Lightning Network will require my bitcoins to be locked up...
You do realize that no one wants their bitcoins to be locked up?

A:
If your interpretation is that Lightning will make your money less accessible, then you are clearly misinformed.
The fact is that your money will actually become more accessible when held in a Lightning channel.
First of all, you do not need to wait for conformations in a Lightning Network, your money can be moved almost instantly within this network.
Second, bringing your money “back on chain” is just as easy as sending a normal bitcoin transaction. You just wait for the first confirmation and your money is no longer “off chain”

The only exception is the rare case that your channel breaks down in the middle of a transaction (counterpart goes offline)       

In this exceptional case; you will be subjected to a short time delay before you can spend your money. The length of this delay will vary; depending upon the parameters you have applied to your channel. 


Q 10:
Will a Lightning Network have its own blockchain?

A:
No, Lightning is dependent on the bitcoin blockchain. On-chain bitcoin transactions are needed to open and to close “channels” between peers (nodes) in the network.
Once a channel is open, the ownership of bitcoin can be transferred off-chain in both directions.
The transactions inside a channel are real bitcoin transactions, but they are not broadcasted to the bitcoin network as long as the channel stays open.
Instead those involved in a channel will store the transactions locally.
This enables instant transactions and a near unlimited capacity within a Lightning Network.


Q 11:
Will there be any form of mining to secure the Lightning Network?

A:
No, security is provided by the bitcoin miners in the underlying bitcoin network


Q 12:
The main chain of bitcoin is secured by a hash rate of 2 ExaHash/s, but a Lightning Network doesn't have any hash rate at all...
So how can a Lightning Network be as secure as the main chain?

A:
The security in a Lightning Network is extracted from the underlying Bitcoin Network.
A Lightning Network cannot operate on its own; it is completely dependent on the underlying bitcoin network for security.

Basically the bitcoin network takes the role as a safety net underneath the Lightning Network. If something goes wrong in a Lightning channel (like your counterpart going offline) you will always have the option to fall back into the safety-net.
(You simply broadcast the latest state of your channel as a normal on-chain bitcoin transaction)


Q 13:
Does a Lightning Network have its own public ledger or some sort of database of all transactions?

A:
No, a Lightning Network does not have its own ledger and there is no database.
Holding value on a Lightning Network means that you are in possession of double-signed transactions. The transactions are valid, but they are not yet broadcasted to the Bitcoin Network.
The transactions you are holding are of the 2 of 2 multi-signature type.
Both you and your counterpart will sign, and you will both store the transactions locally.

These transactions will use a multi-signature address as their input (the funding address)
and they will point at two different addresses for their output.
One output is pointing to an address that only you can control, and the other output is pointing to an address that only your counterpart can control.


Q 14:
How can you say that the Lightning Network is using real bitcoin transactions?
You do realize that it’s not a real bitcoin transaction if it’s not recorded on the blockchain?

Short A:
To understand this we first need to understand what a bitcoin transaction really is…
The fact is; That there are no “coins” in Bitcoin…
There are only signed messages and updates to the blockchain.

So lets say that Alice is sending 1 bitcoin to Bob…
We call this a per-to-per transaction due to the fact that the ownership of value is transferred directly from Alice to Bob.
But Bob does not actually receive a “digital coin” from Alice.
The thing that in reality is happening; is that all the nodes in the network will update their local copy of the public ledger.
The public ledger is updated so that; the “coin” that was before registered in an address controlled by Alice, is now instead registered in an address controlled by Bob.

Long A:
The bitcoin transaction that Alice is sending to Bob, is in reality just a signed message that Alice is broadcasting to everybody.
The message is not only received by Bob, but it is broadcasted to all the nodes in the network.

At the time of writing there are more than 5400 so called “full nodes” in the bitcoin network.
The following steps illustrates the process that takes place when Alice is sending a bitcoin transaction to Bob:

1. When Alice is broadcasting her signed message (= bitcoin transaction), it will be picked up by some of the full nodes in the network.

2. These nodes will independently validate the message (transaction) in accordance with the consensus rules. If the nodes find the message to be valid; they will broadcast the message again so that it can be picked up by other nodes on the network.

3. Some other nodes on the network pick up the message, and this process continues until all 5400 nodes have independently validated and re-broadcasted the message (transaction)

4. At some point a miner will succeed in constructing a valid block that includes the message (transaction) from Alice. To make this happen the miner must bear the cost of an enormous amount of electricity.

5. The miner will now broadcast this newly found block. The new block will be picked up by some of the full nodes. The nodes will independently validate the block and all its content.
By doing this they are also validating the message (transaction) from Alice for a second time.
If the nodes find the block to be valid (in accordance with the consensus rules) they will broadcast the block again so that other nodes can also receive the block.

6. Other nodes will pick up the block, validate and broadcast.
This process continues until all the nodes in the network have independently validated the block and thereby also validated the message (transaction) from Alice for a second time.

The six steps above demonstrate that a normal bitcoin transaction from Alice to Bob actually involves everyone on the network.
The message is independently validated two times by 5400 nodes (= 10 800 validations)

Despite this we are still calling it a “per-to-per transaction” because the actual ownership of value is transferred directly from Alice to Bob*
(*But everyone still needs to help by updating their local copy of the ledger)   

Conclusion:
A bitcoin transaction is just a signed message.

So lets say that Alice wants to send 1 bitcoin to Bob within a Lightning Channel.
Alice is storing some of her money in a “2 of 2” multi-signature address.
Alice and Bob will both sign a message that transfers the ownership of 1 bitcoin from Alice to Bob.
This message is a valid bitcoin transaction, but it is not broadcasted to the bitcoin network.

Instead Alice and Bob both store the transaction (message) locally.

From Bob’s point of view this “double-signed message” has a monetary value of 1 bitcoin.
The monetary value of 1 bitcoin comes from the fact that Bob can spend the money
on-chain at any time by simply broadcasting the message to the bitcoin network.

Bitcoin transaction = Signed message = Lightning transaction

The purpose of any monetary transaction is to change the ownership of value.
In the bitcoin network we change the ownership of value by the use of signed messages

A Lightning transaction is a double-signed message,
therefore a Lightning transaction is a real bitcoin transaction


Q 15:
I have heard that there will be some fees involved in the Lightning Network..
Who will be collecting those fees?

A:
Potentially anyone who is running a Lightning-node.
Example:
Alice wants to send money to Carol, but Alice does not have an open channel with Carol.
But Alice has an open channel with Bob, and Bob has an open channel with Carol.
Instead of opening a new channel with Carol, Alice can route the payment trough Bob:
Alice - Bob - Carol.

In this scenario it is possible for Bob to take a small fee.


16 Q:
In the above scenario; what is preventing Bob from just stealing the money in transit?

Short A:
Bob is actually paying out to Carol first, and then afterwards Bob will get his money back from Alice.

Long A:
1. Carol starts the process by producing a random number ( R ) that she will keep as a temporary secret.

2. Carol then generates a hash ( H ) of R
 
3. Carol gives H to Alice

4. Alice constructs a special transaction that can transfer money from Alice to Bob. But this transaction is only valid if R is included. At this point the transaction is not valid due to the lack of R. Alice also gives H to Bob, and Bob knows that H is the hash of the missing component R.

5. Bob will now construct another special transaction that can transfer the money from Bob to Carol. But this transaction is also only valid if R is included. At this point the transaction is not valid since Bob does not have access R.

6. Carol wants her money, so she reveals R to Bob; thereby making the transaction valid.

7. Since Bob is already in possession of the transaction made by Alice, he can just include R and that transaction also becomes valid. Bob knows that he has been given the correct R because he can check that H is the hash of R.

8. At the same time Bob also reveals R to Alice.
Alice can now use R as proof that she has paid Carol (R becomes the receipt)


Q 17:
Where can I find more information about Lightning?

A:
http://lightning.network/
 
https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-286-drinks-on-a-lightning-network

https://letstalkbitcoin.com/blog/post/the-lightning-network-elidhdicacs

https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md

https://www.youtube.com/watch?v=8zVzw912wPo
18  Bitcoin / Development & Technical Discussion / I have made a Lightning FAQ – Feedback appreciated! on: November 30, 2016, 06:10:07 PM
Q:
What is the Lightning Network?

A:
The Lightning Network is currently under development and will become a decentralized network that enables instant off-chain transfer of bitcoin between counterparties without the need of a trusted third party.
The system utilizes bidirectional payment channels that consist of multisignature addresses.
One on-chain transaction is needed to open a channel and another on-chain transaction will close the channel.
Once a channel is open, value can be transferred instantly between counterparties, who are exchanging normal bitcoin transactions, but without broadcasting them to the bitcoin network.
New transactions will replace previous transactions and the counterparties will store
everything locally as long as the channel stays open.


Q:
Is Lightning open source?

A:
Yes, Lightning will be open source. Anyone can review the code just like the bitcoin code.


Q:
Who owns and controls the Lightning Network?

A:
Similar to the bitcoin network, no one will ever own or control the Lightning Network.
The code will be open source and free for anyone to download and review. Anyone who wants will be able to run a node.


Q:
Who is behind the Lightning Network?

A:
Joseph Poon and Thaddeus Dryja wrote The Lightning white paper. Anyone who wants can contribute with the development of code. Blockstream currently has one employee who is dedicated to Lightning development


Q:
Does the LN have its own “Lightning coins”?

A:
No, that’s not how the LN works. The LN will be using real bitcoin transactions with actual bitcoins in them


Q:
Is the LN dependent on consensus to be implemented?

A:
No, the LN builds an additional layer on top of the bitcoin network and is therefore not dependent on consensus in the bitcoin network itself.


Q:
I have heard that there will be some fees involved in the LN, who will be collecting those fees?

A:
Potentially everyone who runs a Lightning-node.
Example:
Alice wants to send money to Carol, but Alice doesn’t have an open channel with Carol.
But Alice has an open channel with Bob, and Bob has an open channel with Carol.
Instead of opening a new channel with Carol, Alice can route the payment trough Bob:
Alice - Bob - Carol.
In this scenario Bob might take a small fee.


Q:
Will there be any custodial risk in the Lightning Network? Do I have to trust anyone else to hold my money?

A:
No, the system is not based on trust; you remain in full control of your money. If anything goes wrong you simply broadcast your state to the bitcoin blockchain and all your money is returned to you.


Q:
Does the Lightning Network have its own blockchain?

A:
No, Lightning is dependent on the bitcoin blockchain. On-chain bitcoin transactions are needed to open and to close “channels” between peers (nodes) in the system.
Once a channel is open, bitcoin can be sent off-chain in both directions within the channel.
The transactions inside a channel are real bitcoin transactions, but they are not broadcasted to the bitcoin network as long as the channel stays open.
Instead those involved store the transactions locally.
This enables instant transactions and a near unlimited capacity within a channel.

Q:
Will there be any form of mining in the Lightning Network?

A:
No, security is provided by the bitcoin miners in underlying bitcoin network


Q:
Where can I find more information about Lightning?

A:
http://lightning.network/
 
https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-286-drinks-on-a-lightning-network

https://letstalkbitcoin.com/blog/post/the-lightning-network-elidhdicacs
19  Bitcoin / Development & Technical Discussion / How to destroy Bitcoin with a 10% attack: Roadmap for a Central Bank Takeover on: November 27, 2016, 01:25:00 PM
Recently the ECB (European Central Bank) officially warned about the dangers of bitcoin: http://www.zerohedge.com/news/2016-10-19/ecb-wants-curb-bitcoin-use-over-fears-it-may-lose-control-over-money-supply

So lets imagine that a central bank wanted to take control of the bitcoin network..

Note that the following attack only works if the blocks are not full.

To understand this, we must first focus on the economics in the fee market:

If the blocks are full = the price is set by users:
Miners are simply filling blocks based on the fees that are payed by users.
Users are competing for blockspace, and the price of blockspace is determined by how much the users are willing to pay to send a transaction.

If blocks are not full = the price is set by miners:
Miners are competing to offer the lowest possible price for blockspace. They try to include as many transactions as possible while at the same time excluding those that pays too little in fees.
The price of blockspace is determined by how little the miners are willing to demand in fees.

So lets say that the block size is increased and that the blocks are no longer full...

As a result “The 5 Step Roadmap To Destruction” becomes possible:

Step 1:
Wait 7.5 years, by then the block reward will have dropped to only 3.125 bitcoin per block.
At this point the miners have become dependent on fees as their main source of income.

Step 2:
Get control of 10% of the total hash-power in the network.

Step 3:
Start processing all transactions for free.
This will have a global effect on the fee marked. The price of blockspace will simply collapse. Users are no longer required to pay to get their transactions into a valid block.
The result is that all miners loose their main source of income. 

Step 4:
Since the attacker is a central bank, they have access to unlimited resources.
The attack is continued until all other miners are bankrupt due to the lack of income from fees.

Step 5:
The central bank becomes the central processing entity of bitcoin. All other miners are now out of business since they are no longer able to collect fees.

Conclusion:
To avoid this attack we must keep the blocks full so that the price of blockspace is set by the users and not by the miners.

Please let me know what you think about my attack scenario. Thank you for reading this post!
20  Bitcoin / Mining speculation / The intrinsic value of blockspace on: October 23, 2016, 02:27:17 PM
Anything written on the blockchain becomes permanent provided that bitcoin keeps surviving.

Written on the blockchain is therefore the digital equivalent of “carved into stone”

“Written on the blockchain” = “Set in stone” 

I strongly believe that this property gives intrinsic value to the blockspace.

My hope is to spark a discussion around this topic, and I want to ask you the following three questions:

A:
Is it important to maintain the intrinsic value of the blockspace?
Is this property of any importance to the bitcoin network?

B:
How can we best maintain the intrinsic value of the blockspace?

C:
What is the best mechanism to determine the price of blockspace?


The price of blockspace will always be determined by the market...
But the process used to set the price will depend on some fundamental conditions in the market:

If the blocks are full:
Miners will simply fill the blocks based on the fees that are payed by the users.
Users are competing for blockspace, and the price is determined by how much the users are willing to pay for the blockspace.

If blocks are not full:
Miners are competing to offer the lowest price for blockspace. They try to include as much as possible while at the same time excluding those who pays too little.
The price of blockspace is determined by how little the miners are willing to demand in fees.

Please let me know what you think about A, B and C!

Thank you for reading this post!
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!