Implicitly the network would make it impossible, that Alice spends the funds after CSV (and Bob executed the tx). If Alice then spends, it would be a double spend? So question remains, if Bob did not execute the tx, then how to prevent Alice from still spending it? When there is no direct possibility, a workaround might be to extend first condition? IF
2 [alice pubkey] [bob pubkey] 2 CHECKMULTISIGVERIFY
ELSE
[time] CHECKSEQUENCEVERIFY DROP
[bob pubkey]
ENDIF
CHECKSIG |
|
|
|
On the other hand, referring to the account status is kinda lame argument. I don't know what reasons people have to crate new account and I accept the fact it's not my business. I prefer to think that Established account probably know things, but newbie account may or may not have knowledge. We should not deny people privacy by simply discarding posts from fresh acc. (My acc for example is not my main)
that's kind of an elegant way to express acceptance, that (n)etiquette can be ignored. Maybe no, or not in my humble opinion.... I'd rather see newbies to introduce, observe, understand (! - and show, that an effort was made to understand!), then comment (open questions), discuss, and then (if progress in knowledge is proven) allow to critisize. And of course don't insist others have to prove, how far they are wrong. I think I am looking more at reputation not privacy. On the technology: bitcoins must not be the only ramp on/off to the lightning network. Once I have coins in lightning, there is no reason to close the channel after every transaction. Au contraire, I could develop new business models around "my" coins in the channel. Last recently I discussed the value of having coins in the channel, while someone else needs to quickly send funds, but current congestion and fees prevent him to do so... And looking at the fees that large exchanges pay as per today, I guess they would be the first candidates to think about lightning channels (or cost reduction). Also bitcoin faucets, marketing hubs and regular payment services come to mind. I consider this to be the mesh network, which is clearly decentralized. Only commies would want to have lightning centralized:-) Whereas I can't predict the future, I would think that reducing tx costs is a driver for moving to technology, in this case to Lightning. |
|
|
|
Exactly. Even with LN, the current 7 transactions/sec world wide is a joke, not even close enough to make this a viable solution. It's doomed to fail, unless they improve the onchain throughput rate. But if they do that, why do they need LN in the first place ?
calling this a joke as a newbie here in the forum will not gain you friends. Too many newbies have come here and repeated the "flaws" of Bitcoin design. Looking at your posts seem to show a misunderstanding of how Bitcoin AND LN can work in the future together. You are looking with limitation glasses (the fees), instead of the options glasses. Your calcs are based on wrong assumptions (well, very limited assumptions to make it appear worse). It might even be that you do it with intention: to show that big blocks are better/faster/lower fees ... this is lame, and there is other forum pages. Especially as there isn't in any visible real value in these big block coins (yet). So be happy in your big block coins, and hope for the future. Those, who know better, stay with bitcoin, segwit, LN and more to come. Maybe you might want to re-phrase into open questions, so the community can discuss/answer properly, and it helps the community to get along. Without separating between one or the other. If you continue this way, your comments cannot be taken seriously, and as such don't provide any value. |
|
|
|
The transactions have to be decoded anyway, so pushing them through a bunzip2 should not be that dramatic.
In exchange, you could reduce fees to about a third and increase transactions per block 3 times (more or less, one would have to test with a significant number of transactions to get the average compression rate).
With fees going through the roof and tx/s being rather low, I don't see why increasing the tx rate would be bad.
There must be some soft facts, that were not yet expressed, which prevents from doing so. Where would compression/decompression affect the ecosystem? - a full node at the initial load of blockchain: verifies each tx - so the time get's increased - during creation of new blocks: each miner has to decompress the tx, adding a bit of time - a small block with only a few tx will not benefit much (but currently vast majority of blocks are filled with a substantiate amount of tx) - it might be a hardfork (ugh), or vice versa, serious thoughts must be put into making it a soft fork (approach/thought/idea: similiar to the way, segwit tx are forwarded to non-segwit nodes, same logic could apply to compressed tx) + with Moore's law: processing power is increasing faster than network bandwidth, so a good point for compression + compression during transfer on the network: decreases the amount of data to be transferred, reducing load, reducing latency, positive network effects + for the "end user": reduced tx size reduces fees, a quick bargain at current times (but against interests of miners?) + the bigger blocks get (with many tx), the better size reduction is achieved there are way more... I searched through the forum, if this wasn't discussed already. Nothing really found. Whenever such a topic is discussed, it quickly runs into overly complex discussion about possible implications in the future, which boils down into sovereignty over the interpretation of implications. Only response to this would be a real "measurement": how much impact? --> do a test setup and proof   |
|
|
|
Another "weak" area in many LINUX systems are the blobs (eg. the graphic cards, the wifi cards, and more). For sure you don't need graphics or wifi on your (cold storage) signing system. OpenBSD can be an alternative here  I can further minimize the risk with cold storage and multisig. But as usual, security is a trade-off between costs and comfort. It sure is easier to have a hardware wallet. |
|
|
|
...
The areas where legal service industry will be revolutionized include Smart Contracts and Intellectual Property Rights
Smart Contracts
Although not part of Bitcoin, Smart Contracts are invariably linked to blockchain technology...
What do you mean by saying, bitcoin has no smart contracts? Can you outline your statement? I would say, there are smart contracts possible in bitcoin... |
|
|
|
In general, it is clean for me.
really? just kidding... script is a fundamental part of the way, the bitcoin system works. But i can not understand for what transaction scripts are needed?
next to the links already provided (and I really recommend reading Andreas' book "Mastering Bitcoin", these scrpts make sure, that only the defined target user (or owner of that address) can spend a transaction. Why was this introduced? Difficult to say, but based on previous developments, one had to make sure, that in a P2P world, there might be malicious actors. So one had to make sure, that you can not spam the network, you cannot double spend a transaction, you cannot create values out of thin air... all this has to do with the scripting. It seems for any transaction the script is same, so , why it is used here? no, definetly not!!! There are two parts in a transaction, which conatin scripts. In the input section, and in the output section. The input section contains the condition, which must be met, so the funds can be transferred from the previous address to a new address. The output section contains a script, that proves, that "I" had the correct keys, to be able to move the funds. This all has to do with cryptographics (especially hashing and signing, you will step over the words of ECDSA...). If interested further, the links above explain alot, and here is two links, explaining the signing process and more: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.htmlhttps://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx |
|
|
|
These multisig tx can come from everywhere. Everyone is free to create such a tx. Your question cannot be easily answered in one step, so a good reading would start here: https://bitcoin.org/en/developer-examples#p2sh-multisigand also in Andreas' book "Mastering Bitcoin". (it is online available/readable). There are two types of multisig tx, each having different aspects, but the "P2SH" version with a redeem script should be used nowadays. The idea behind a multisig transaction is, that you use two or more signatures, to make the transaction valid. You can compare this to a cheque payment, which needs to have two (or more) signatures to be accepted by your bank. How to create such a tx: as per the reading above, that also depends on your wallet. Assuming bitcoin core, Gavin gave one of the first examples: https://gist.githubusercontent.com/gavinandresen/3966071/raw/1f6cfa4208bc82ee5039876b4f065a705ce64df7/TwoOfThree.sh |
|
|
|
...Short answer is that this is an unsolved problem in crypto currency, unless you're using an ethereum contract...
what??? unsolved problem? How do you derive this statement? What is unsolved? Can you outline, what ethereum can do here? Transfer funds from bitcoin to eth, just to do a later payment, and then back to bitcoin? Or are you just repeating the standard meme "smart contrct = ethereum", without respecting the original question? In this very long thread on smart contracts others explained the possibilities for smart contracts as per today, and I added some references. They fit exactly to the authors needs. No switch to ethereum or turing completeness or solidity required. https://bitcointalk.org/index.php?topic=2204938.msg23664225#msg23664225 |
|
|
|
ugh, my soul has been stolen. probably the best post to terminate this unbelievable dumb thread here |
|
|
|
The reason everyone verified signatures in the past is it was so quick (a few microseconds) to do that ...
I am trying to bang my head around your ideas.  I cannot come to a conclusion  Is it looking for a flaw in the design (so far this was very poor), or just to challenge the audience and keep them busy? DannyHamilton, HeRetik and achow121 all explained, why your assumptions are wrong, still you insist on cancer, epidemic stuff, domino effects and other buzz words. You have posted in several threads here in this forum, with a theory, that is not accepted, and you already had fairly harsh comments on it. You do not show, that you have understood how the network (network is not miners) works, and could not underline this knowledge with hard facts (e.g. mathematical proof, in CPU seconds for sig verification, or what it means in Euro/Dollar/Pounds). In your last post you are asking DannyHamilton, to provide the figures, but hey, that's not how things work! You post a statement, it is up to you to underline it with reference data, otherwise it's wasting our time. Or you'd be ready to pay for someone to underline your logic... Your wording is repetitive, stating that it is more beneficial (than what?) for a miner to work against the network, instead of playing the game. Miners will make more money by not checking the signature data when they verify transactions. Besides that this statement is lacking fundamental data, I try to turn it a bit around: the incentive that miners have to check the sigs, is to have valid tx into a block no matter if segwit or not. They can only gain money, if they propagate correct blocks, otherwise they loose potential earnings, and the whole power consumption costs. on verification: it was explained, that every full node verifies the tx (and initially the blockchain), whereas e.g. SPV wallets do not. The danger behind SPV is well known, though people are still using SPV wallets, and others rely on full nodes. Full nodes give the proof (to me !), that a forwarded tx is valid or not, and that I am on the correct set of blocks since inception. If miners want to change the rules, they can do so, and need 51% (maybe even a bit less) - that is well known, and part of bitcoin's design. So let's try to think miners do not verify, then they might waste a lot of their processing power on the "potentially wrong" chain. Until it eventually comes to the point where they propagate with the majority (51%). I think this is, what you try to phrase in your words as "domino effect". But anyhow, words are not sufficient here to gain credibility for the statements made... |
|
|
|
from Andreas' book "Mastering Bitcoin": Locktime, or more technically nLockTime, is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain. We are currently at ~500283, so behind the value in the tx (500114). So the tx is good to be processed by a miner. I see 200 Bytes per Satoshi, also a "good" value, but based on " https://bitcoinfees.earn.com" I guess it will take even longer then the displayed 3-120 blocks... |
|
|
|
I can't see, that the second is multisig. It's tx sig looks like this: WITNESS TXIN[0] stack elements: hex=02, decimal=2
WITNESS[0] data length (var_int), hex=47, decimal=71, data(uchar[]): 3044022027BAC51C3DF47B8C3396D5C2CAE52A272D1B4EB7C02A45465B6D071823469EE202201C349BF199C0A0CFF8F3ED88448B2B6D518EA8298C5803E333ACB8543A0088E901
WITNESS[1] data length (var_int), hex=21, decimal=33, data(uchar[]):
03F42E8010475E2AF03E8AE790C956AD40945FA7C57740FA839FBC6ADF89F5376C
WITNESS [0] decodes to a single sig, with R+S key, and then SIGHASH_ALL:
##################################################################
### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
##################################################################
47: OP_DATA_0x47: push hex 47 (decimal 71) bytes on stack
30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
44: OP_LENGTH_0x44: length of R + S
02: OP_INT_0x02: type tag INTEGER indicating length
20: OP_LENGTH_0x20: this is SIG R (32 Bytes)
27BAC51C3DF47B8C:3396D5C2CAE52A27
2D1B4EB7C02A4546:5B6D071823469EE2
02: OP_INT_0x02: type tag INTEGER indicating length
20: OP_LENGTH_0x20: this is SIG S (32 Bytes)
1C349BF199C0A0CF:F8F3ED88448B2B6D
518EA8298C5803E3:33ACB8543A0088E9
01: OP_SIGHASHALL: this terminates the ECDSA signature (ASN1-DER structure)
curious to see, how this is explained... |
|
|
|
|
whereas the idea of avoiding tax is highly attractive, the consequences are often overlooked.
On the one hand side it is a criminal act, so taking the risk of trusting crypto code and going one day (years later) into prison should not come as a surprise.
What I think is even more important: countries, where people pay regular taxes, have proper infrastructures, which make life easy (see Switzerland, Germany, Austria...). Compare this to countries where people have a faible for not paying taxes. You will find, that their egoism is to the disadvantage of the community. And this creates unbalanced distribution of wealth, where jealousy and envy create a layer of low-level criminality, which then increases to the next layer(s). Looking at third world countries, or BRIC countries, or even the US (probably the most funny example in this enumeration): in principle a very rich country, but the country with the highest amount of people in prison per inhabitants. What a huge problem!
Yup, thinking about tax avoidance is a difficult matter, and bearing the consequences of a short level egoistic thinking might have disadvantages.
|
|
|
|
|
{ethical behavior}
you both do not provide any value to the discussion.
Instead you try to challenge each other with a level of knowledge, which is highly irrelevant to the community, and (if at best) only proves a certain immaturity, developing an arrogance towards "ordinary people", which prevents you to respect others and thus adding value to the discussion.
And insulting language ("being dumb" or "must not interest you") is certainly out of scope of a technical forum like here.
{/ethical behavior}
|
|
|
|
maybe here: http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdfChapter 3: Proposed Hybrid Routing Algorithm
As a way to satisfy the requirements listed in Section 1, we define a hybrid routing algorithm, which we call Flare, consisting of proactive and reactive stages. The idea behind this approach is that the state of LN can be split into two distinct parts:
• slowly changing, or static, information (payment channels between nodes)
• quickly changing, or dynamic, information (status of nodes, distribution of funds within pay- ment channels, fees for using a channel, etc.) and then follows a long text on routing possibilities. If you are familiar with the way how networks in the IP world work, you find it quite easy to read, otherwise there'll be a learning curve :-) I think I read somehwere a comparison to border gateway protocols, but couldn't find it right now... |
|
|
|
|
Show Posts
