Bitcoin Forum
December 11, 2018, 07:00:42 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [30] 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 ... 547 »
581  Bitcoin / Development & Technical Discussion / Re: Cascading Bitcoin Nodes on: January 29, 2018, 10:14:38 PM
I don't think a node will serve blocks to any other node until it is fully synced. So if your first node is not synced yet, you should wait for it to be fully synced and then try again with the second node.
582  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.15.1 Released on: January 29, 2018, 03:49:15 PM
Is there any different between bitcoin and bitcoin core? And how do I create account for bitcoin core?
Bitcoin is the name of the coin. Bitcoin Core is a full node software for Bitcoin. They are not two separate coins, but they are different things. You do not create an account for either Bitcoin or Bitcoin Core. You need a wallet, which Bitcoin Core is.
583  Bitcoin / Armory / Re: 0.96.3 Stuck scanning - 1 second forever on: January 29, 2018, 03:46:52 PM
Try using 0.96.4 RC3 available from here:
584  Bitcoin / Development & Technical Discussion / Re: MuSig: Schnorr Multisig and signature aggregation on: January 29, 2018, 01:27:05 AM
also known as a k of n multisig
this means that in a 2-of-5 multisig where 3 people dont have to sign,

as oppose to
interactive, where by its n of n, meaning it has to be a 5 of 5 or a 3 of 3 where everyone has to sign
No, that is not what interactive means.

In traditional cryptography, interactive means that the participants in the multisig must verify that the other participants actually control the private keys to their public keys, not that it is n-of-n. Non-interactive does not mean that it is k-of-n, it just means that there is no key exchange and verification protocol that must be executed.

Anyways, MuSig is specifically an n-of-n multisig scheme as it is a multisig scheme in the context of traditional cryptography.

this means when users see the funding public key, they dont know how many other signers there are or are needed in total
The same is with current multisig using P2SH. Hell, you don't even know whether a given P2SH address is multisig or not, so if you are a participant in any multisig, you should always be asking for the redeemScript, or, if using something based on MuSig, you should be asking for the public keys involved and make sure they calculate to the given aggregate public key.

and when the funds do move.. never get to know who specifically did sign

because the address doesnt tell them it is a 2 of 5..
because the address doesnt tell them who the other 4 people are

making it easy for whomever set it up to tell 3 guys its a 3 of 3 when in reality its a 2 of 5, and in reality whomever set it up owns 2 keys himself

so the 3 innocent guys dont realise its a 5 counterparty address.. all they can see is that their key is part of AN address.. but not know how much of a part...
This is completely incorrect, did you even read the paper or the linked blog post?

As I said earlier, MuSig is only a n-of-n scheme so this concern is completely invalid. To do k-of-n, additional work is required.

I don't quite get yet how the k-of-n threshold scheme comes in (maybe it's out of the scope of that paper?), but in general, this is great news. I hope a BIP detailing the actual implementation into Bitcoin will be forthcoming soon.
k-of-n is out of scope for the paper. MuSig is only n-of-n, but with additional Bitcoin specific things, can be done in a k-of-n fashion.
585  Bitcoin / Bitcoin Technical Support / Re: Lightning Questions on: January 29, 2018, 01:12:36 AM
I consider joining in and be #reckless. I have some design questions though. Under the premise that I mostly dont want to spend funds and want to help process transactions and establish cheap path's along the network. Currently the topology[1] looks to me like there are a couple main hubs and everyone else just attaches to them.
Currently the network is still fairly small. But if you look closely, the network is really not a hub and spoke network. Even if many people have channels with these "main hubs", many of those nodes also have channels with other nodes too. The "hubs" thing right now is probably because there are only a few services that accept LN on mainnet and people are just connecting directly to them in order to pay.

#1 (how connect?) What would be a good approach to establish alternative paths? Connect to all bigger hubs, e.g. all with x+ connections? Or rather establish a connection between other nodes within the network that are not already connected via a single hop?
I suggest you take a look at how LND does autopilot mode. It takes in various inputs and uses a model to figure out what channels are the bets to open. You can read about it in the release notes here:

#2 (resource requirements?) What (additional) resources are required? Has anyone data on this? I consider upgrading my server anyway, so this would be a good switching point.
LND does not need much more resources than those that are already required for running a full node (because you need a full node). You can also not run a full node and instead run it in SPV mode which uses BIP 157.

#3 (minimal funds/channel?) The current total capacity is only(?) ~3.68 BTC (again according to[1]), what would be - in your opinion - a good amount to put aside per channel? As much as possible obviously, but at which point does it become too little? Considering I plan to invest X amount of BTC this "minimal amount" would limit the number of channel I could reasonably keep open.
The current protocol limits channels to 2^24 (16777216) satoshis. There is no minimum funds; you can open channels or request channels to be opened where you provide no funds into the channel. IMO putting 0.01 BTC in a channel is reasonable.

#4 (is much work?) How much maintainance is needed? Funds would move between channels, but the main flow may be in a certain direction along the path. Because people just buy stickers instead of sending funds back and forth. Has anyone any experience with this yet?
At least on testnet, there doesn't seem to need much maintenance. The available software are capable of handling things automagically.
586  Bitcoin / Development & Technical Discussion / Re: c-lightning on testnet: problems and questions on: January 29, 2018, 12:57:59 AM
c-lightning coexists with bitcoin core whereas right now lnd doesn’t.
LND has the option to use Bitcoin Core as the full node backend.
587  Bitcoin / Bitcoin Technical Support / Re: BitcoinD RPC Server on: January 29, 2018, 12:49:59 AM
Thanks! For anyone else reading, I noticed that bitcoin-cli worked properly when bitcoind was invoked via the command line, but not when running the GUI.

Adding "server=1" to bitcoin.conf fixed this issue.
bitcoind will default to server=1. bitcoin-qt will not. So if you want to use the RPC server while running bitcoin-qt, you need to set server=1
588  Bitcoin / Bitcoin Technical Support / Re: Questions on - Signature aggregation and Lightning networks on: January 29, 2018, 12:48:38 AM
This argument relies on a model where the Lightning Network is in a degenerative case where it is a linked list and not a well connected graph. From current testing and use of the Lightning Network on both testnet and mainnet, we can clearly see that the Lightning Network is not this degenerative case and is instead a well connected graph. If a channel is chosen as part of a route going one direction, it can also be chosen for a similar transaction going the other direction, and that would re-balance the channel.

Furthermore, you can limit how much you allow in routes through your channels. So if B wanted to ensure that he still had money to pay C, he can refuse to route A's transaction of 10 BTC. A would instead have to find another route, which, given a well connected graph, is not very hard.
589  Bitcoin / Bitcoin Technical Support / Re: Dealing with Bitcoin hackers on: January 29, 2018, 12:39:24 AM
  • Redirect them to a file which contain a malware, a virus or an insult
  • Redirect them to a file which contain a script that will mess them (wait forever, hang their PC, etc.)
I would suggest that you not try these as those are things that can get you in trouble with the law. Well, having an insult is fine, but distributing malware is not.
590  Bitcoin / Development & Technical Discussion / Re: [LN] What is the typical payment channel expiration time? on: January 29, 2018, 12:35:51 AM

What you say changes my fundamental understanding of how LN works (or rather makes me think I don't really understand it).

From Wikipedia:

Isn't this transaction should be time-locked? I always thought about revocation as a spending hashlocked output back to myself while time-lock have not expired (if that makes any sense).

Also from here i get the impression that channel has limited lifetime (even though he speaks about unidirectional channel in this part I don't see how it's fundamentally different from bidirectional channels).
No, the revocation key is only used for the punishment transaction for broadcasting an old commitment transaction. The revocation key is only known after both parties in the channel have agreed to revoke a commitment transaction and replace it with a new, updated one.

The only thing with timelocks in LN are HTLCs (it's in the name) which are only used for routing payments to other people.
591  Other / Meta / Re: Can a newbie become a merit source ? on: January 26, 2018, 05:04:31 PM
Merit sources tend to be higher ranked and trusted members who have a history of making quality posts. A newbie does not have that history of quality posts nor are they trusted. Those come with time and experience. Thus it is unlikely that a newbie would become a merit source.
592  Bitcoin / Development & Technical Discussion / Re: How to calculate transaction fees ? on: January 26, 2018, 04:03:10 PM
Then: a*180 + b*34 + 10 +/- 1
Unless you are using uncompressed public keys (and very few wallets do this anymore), the input multiplier will be 148 instead of 180.
593  Bitcoin / Development & Technical Discussion / Re: [LN] What is the typical payment channel expiration time? on: January 26, 2018, 03:56:21 PM
Channels do not have an expiration time. The commitment transactions are not timelocked, nor are they HTLCs. The HTLCs are used for routing payments, and those are timelocked.

Looking through my open channels and through the network graph, it seems like a timeout of 144 blocks (aka 1 day) is the most common.
594  Bitcoin / Bitcoin Technical Support / Re: Why need bitcoin source compiling? on: January 26, 2018, 03:51:39 PM
Bitcoin Core is written in C++ which is a compiled language. Thus it needs to be compiled in order to be run. Compiled languages are used because they give more control over memory management and are more efficient and optimized/optimizable than scripting languages which do not need compiling.
595  Bitcoin / Development & Technical Discussion / Re: Will Lightning Network be able to deploy forks in future? on: January 25, 2018, 07:47:22 PM
oh yes you need consensus if you send a single transactions across 20,000 nodes because they are not received in order by each node
so a kind of vote takes place to decide the winning combination

That's not at all how lightning works.

Does having more nodes increase the overall speed of the network or reduce the speed !
Neither. It does neither.
596  Bitcoin / Development & Technical Discussion / Re: MuSig: Schnorr Multisig and signature aggregation on: January 25, 2018, 07:44:44 PM
Soft fork? I wonder if it's possible since MuSig use different signature format which older nodes won't able to recognize or there will be backwards compatibility just like SegWit where older nodes only can see non-witness data?
The fork would presumably use the witness program versioning thing that segwit introduced. This would mean that it uses a new witness program version, so older software will just ignore it as it is a new version it does not understand.
597  Bitcoin / Development & Technical Discussion / Re: Will Lightning Network be able to deploy forks in future? on: January 25, 2018, 07:08:55 PM
It's a part? Means it can be called sub-blockchain to let others transact off-chain?
No. It is not a sub-blockchain. LN is not a sidechain. LN is not a blockchain in any way, shape, or form.

But, as there are on-chain forks possible, there may come something like off-chain forks too if they are not satisfied with the delivered results and there may arise problems with it too (maybe) where an upgrade may be expected and a "possibly soft if not hard" fork may be required?
LN does not require any consensus changes. It itself has no consensus protocol. Thus there is no way to have a fork because there is no consensus to change. The LN protocol is extensible, and changing it just means bumping a version number. There is no forking.
598  Bitcoin / Development & Technical Discussion / Re: Will Lightning Network be able to deploy forks in future? on: January 25, 2018, 06:58:27 PM
The lightning network is not a fork nor does it do anything with Bitcoin's consensus rules. It can't really be hard forked unless the underlying asset (aka Bitcoin) is forked. LN works on top of the blockchain; it is not its own separate coin with its own consensus rules.
599  Bitcoin / Development & Technical Discussion / Re: MuSig: Schnorr Multisig and signature aggregation on: January 25, 2018, 05:38:25 PM
What will the activation threshold be? I think it was 95% for 2 weeks for BIP141 or something like that innit?
It will likely be the same as that is just following the BIP 9 specification.

Again, there currently is not BIP nor is there an actual proposal for using this in Bitcoin yet. We won't know the actual details until that happens.
600  Bitcoin / Development & Technical Discussion / Re: What are the fees on the Lightning network? on: January 25, 2018, 05:36:23 PM
I don't think LN has gone live and was expecting a wait of 9 months to a year so do you have a
link please or are you talking about testnet
There are already people using LN on mainnet. There does not need to be a release of LN (whatever that means) or for it to "go live". It's not a central thing where one group can announce that it has "gone live".

Some stats about the LN mainnet can be found here: A graph of the nodes can be found here:

Multiple people are accepting LN mainnet payments such as TorGuard: and Blockstream:
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [30] 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 ... 547 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!