|
I connected to you, and got 2 connections back at the same time?
What did you do?
|
|
|
|
There are about 50 people in the #lnd channel on freenode. Join up here if you need quick link: https://webchat.freenode.net/This is primarily for the Go implementation of Lightning, but once they are compatible with the spec set out between them, we can all test between 4-5 implementations. URI is: 02eff3b9ec986e8691b5b41e944acd9d20b9c36c8c50c2674239242eee9bfacc4a@127.0.0.1:9735 Here is my payment request: 02eff3b9ec986e8691b5b41e944acd9d20b9c36c8c50c2674239242eee9bfacc4a:1000000000:dabe2b56d45fd64df25364a5e2706834aad8510c9bf2be7b023ed70dcd55f7e5 This is for 10 milliBTC. But I am currently not connected to any channels, so you wont be able to route that payment to me, we need to connect to each other first. |
|
|
|
|
I have tested this extensively, but only alone and not with other people.
I will post you my node and we can do this. Are you on IRC and we can coordinate things better then. Maybe get some more people going, and at least test Eclair better, until the Lightning Go implementation is fully BOLT compatible, and then we can really test it big time.
|
|
|
|
|
Is this coin a 1:1 copy of Bitcoin, or did you change other parameters as well?
|
|
|
|
|
There is no need to compromise with BU. It is a broken implementation that gives miners power to decide block sizes and is nothing but a political tool invented by those that want to see Bitcoin become centralized. Why would anyone compromise when the solution that is ready is superior in every way and also increases block size?
|
|
|
|
A cornerstone of payment channels seems to be the idea of pre-images and their secret being communicated through the network. But when it comes to the definition of the pre-image itself, and its properties in terms of how it works within a technical system, such as payment channels, there is little information anywhere. The closest I came to information about pre-image was the mathematical description of it here: https://en.wikipedia.org/wiki/Image_%28mathematics%29#Inverse_imageWhen talking in terms of cryptography, anything I have been able to find was how pre-image is put together as a pre-image attack on hash functions, but not a description of how the pre-image itself, and its construction for being used as a secret in for example payment channels actually works. Anyone care to chip in some info on pre-image and how it relates to the crypto/hash of payment channels in more details? |
|
|
|
|
When looking at the operation of sidechains and the way that they are supposed to atomically swap, it makes perfect sense, in terms of two sidechains that both carry the code to allow for such.
This would however be executed on chain, rather than off chain, as in the lightning-esque fashion. Most atomic swap transactions would most likely be off-chain, in between multiple chains, while the on-chain atomic swaps would probably carry quite some significance to be done on-chain.
From the Lightning page it describes shortly that chains that support the same cryptographic hash function, would be allowed to swap in the secondary layer, the channel layer.
Can someone clarify exactly what an off-chain transaction exactly is in this instance? For example between Bitcoin and a sidechain (when SegWit is enabled on Bitcoin).
Would it not mean that a sidechain's payments channel that is swapping for a Bitcoin's bitcoin on a payment channel, or mixing them together to form a third layer of abstraction combination wise, indirectly give value to the token itself on the sidechain, in its secondary layer. I am specifically thinking about a sidechain that is assets based in this case.
Its been bothering me for a while that the lack of PoW on sidechains makes them no more interesting from a security point of view than any other environment. Would a secondary or third layer, after mixing the tokens together, form a more substantial protection for the sidechain asset chain?
|
|
|
|
Whilst this probably won't be understood by nearly anyone on this forum the AT CF code is as follows: 00000000* STZ $00000000
00000005 FUN @00000001 Get_Current_Balance
0000000c BGE $00000001 $00000002 :0000004e
00000016 FUN @00000003 Get_Creation_Timestamp
0000001d FUN A_To_Tx_After_Timestamp $00000003
00000024 FUN @00000004 Check_A_Is_Zero
0000002b BZR $00000004 :00000054
00000031 FUN @00000005 Get_Amount_For_Tx_In_A
00000038 FUN @00000003 Get_Timestamp_For_Tx_In_A
0000003f FUN B_To_Address_Of_Tx_In_A
00000042 FUN Send_To_Address_In_B $00000005
00000049 JMP :0000001d
0000004e FUN B_To_Address_Of_Creator
00000051 FUN Send_All_To_Address_In_B
00000054 JMP :00000054
This is AT machine code (there is no high-level language for AT at the moment and after the DAO bungle we aren't in any hurry to add one), however, it has been in production for well over a year (without a single issue being reported from two separate blockchains that are using it). It is *minimal* and incredibly efficient (it doesn't even basically do any executing until the CF expiry time is reached). I don't think that Turing complete smart contracts are impossible to do right but they are extremely difficult to do right and so should IMO at this stage be limited to very small things like the example above (and tested for every feasibly possible scenario). Where is that data from? |
|
|
|
|
Welcome back.
I would like to point out that it would still be quite interesting if you can add support for accounts and wallets. Its a big part of what some companies need, due to the fact that we have the logic broken down on the accounts level directly from BitcoinD. Having a great overview in command line, vs. the output we have today would be a good features. Hope you can reconsider and have it added.
|
|
|
|
Writing smart contracts is inherently not 'natural' software development similar to how writing legal contracts are not 'natural' prose. The requirements and implications are quite different. The kinds of data the software works with is different. The resource costs are radically different. The execution environment is necessarily very different-- how often do you write ordinary programs whos execution gets rolled back in a reorg or could "run out of gas"? The implications of failure are typical fairly different. The interactions with privacy are very different than ordinary software development. Often the "simply written" smart contracts are grievously insecure-- I guess you could say that they're not that smart.  There can be cases for wanting to use legacy software in a smart contract context, for interoperability or rapid prototyping-- but the ethereum model isn't particular good for that either (it imposes enormous overheads on software compiled from traditional languages). Effectively, when you create a de novo smart contract you are designing a cryptographic protocol. It turns out that it's fiendishly hard to do this, even for experts, and the science of creating good tools for it is yet unsolved. (Though it's one of the long term problem areas that I'm funding people to work on.) I think the Bitcoin technical community has some good starting premises about what kinds of constructs facilitate making tools that make it more feasible to construct new smart contracts with less than super-human effort-- things like having top level building blocks that work like monotone boolean functions, so that you can safely compose standardized parts without understanding the internals and your software can reliably analyze the space of possible outcomes. What is a de novo smart contract? Could you tell us more on what you are trying to achieve in this field you are funding people in? |
|
|
|
|
gmaxwell is the point of payment channels/level-2 layers not to enable more advanced uses of "smart-contracts" ?
From my understanding the Script language will be used to form contracts, but all computation of such will sit outside the blockchain itself.
What I am missing is however the smart-contract construction on this layer and how it will look exactly. Is MAST going to be required before we have a "real" smart contract interface?
|
|
|
|
|
This also implies that we are probably going to get payment channel specific op_codes in the future.
It would for example be interesting to have an opcode that allows for pulling funds, but only applicable to the secondary layer. Would allow us to make credit card type of payments available.
|
|
|
|
|
Rusty said similarly on IRC, and I understand that. But here is something that I dont understand.
If I make a transaction on a payment channel, following all the Script rules, then how does channel funding play a role?
I assumed that funding a channel via op_cltv and op_csv were required only to setup the channel, and thus whatever transaction took place would be "outside" the scope of Script and rely on different rulesets.
If Script is still in use, it implies that all transactions are subsequently recorded in mempool as they are Bitcoin transaction, but with the only exception of that they wont get mined (due to op_cltv/op_csv settings). This sounds, wrong, so I am sure I missed something in terms of the transaction abstraction on secondary layers.
|
|
|
|
|
With improvements in the Script language such as P2SH and OP_CSV, how are they going to be in used on payment channels? Since payment channels most likely write their own logic layer, wont the entirety of the script be negligible, as we can assume settlement on chain will be costly?
Or are payment channels going to utilize the Script language in Bitcoin at the secondary layer as well? I have been unable to find anything on both Lightning implementations as well as the Thunder implementation.
From all I can see, there are no scripting rules. But wont this kill the need for more op_codes as we move ahead with abstraction layers?
|
|
|
|
|
I am writing a piece for a blog, and for historical context I would like to gather as much as possible on work done towards ecash decentralized systems as possible. I am familiar with both Bitgold and b-money. What else do we have out there, and what else was released that pointed towards becoming a Bitcoin-esque system?
|
|
|
|
|
Garbage product by inferior developers pushing an even more garbage agenda
|
|
|
|
The biggest problem with Classic shills is that they can't deal with the fact Bitcoin will never scale anywhere without Lightning Network and no matter how much you raise the blocksize, the only thing you are doing is centralizing the nodes compared to what you would get out of it which is sightly cheaper on-chain transactions (and no one is going to be using on-chain transactions in the future when they realize they can do it for near free with LN and no one is having any problems with it whatsoever).
Just absolutely no idea how to scale protocols these guys.
+1 |
|
|
|
|
If all we are dealing with is M of N shared secret keys here, how come this is more secure than multisig? They seem to argue that deploying DSA to wallets will make them more secure. What am I missing?
|
|
|
|
This new paper here: https://eprint.iacr.org/2016/013.pdf states that it helps with the security of wallets. From my understanding it relies on n >= t+1 servers, where t is the compromised servers. What I am not sure of I understand correctly is how it secures the malicious part is not capable of obtaining all the keys if all servers are breached? Hope someone can elaborate on this topic a bit better. |
|
|
|
|
Show Posts
