bump

What do you think of P2WKH (160bit hash of pubkey) vs P2WSH (256bit hash of pubkey) security?

I tried to do that on android and it's practically impossible to end up with a sane UI for that since it requires to enter full info on unspent outputs. SegWit/BCash protects from entering incorrect amount and producing huge fee but it complicates things even more.

In order to enter unspent outputs info you have few choices - entering raw hex transactions, entering a json from a web service or using a some sort of tx constructor. So for practical point of use it's much easier to use hardware wallets.

Ah, seems I misunderstood the question since a segwit implementation is already in bitcoin core.

There are none, only bitcoin core source code + bips + tests from https://github.com/bitcoin/bitcoin/tree/master/src/test/data
You'll need implement basic bitcoin first,  then bip143 hash (this gives bitcoin cash implementation almost for free), then p2sh, then segwit tx validation.

I wonder how a Lightning user interface would look like. Instead a "Send" button there will be "Open channel" button (same fee as just Send button + X bitcoins to deposit into channel) and then "Send via the opened channel" (no fee) and then "Close channel" (same fee as just Send button). Given this complexity and the fact that you have to spend twice as much in fees to send same amount of money as without LN I really wonder how the "greed" would work.

If you say you need big aggregators like Coinbase... Well, why would a user choose the aggregator instead using um... Zelle for example? Maybe only for transnational payments.

I wonder why getrawtransaction doesn't return proper error like "No indexed transactions, run app with txindex=1".

The only way to introduce that in bitcoin without hardforks is to use a sidechain. Say, based on MimbleWimble.

This actually raises another question that how VerifyScript() works if scriptSig is empty and scriptPubKey "OP_DUP OP_HASH160 1d0f172a0ecb48aee1be1f2687d2963ae33f71a1 OP_EQUALVERIFY OP_CHECKSIG" which fails on OP_DUP with empty stack but it's something I'll have to figure out by myself.

OK, thank you!

It's possible. You can ask the shapeshift for transfer logs :-)

Hi! I'm checking out examples of Bip143 hashing from https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki and there is one thing I don't quite understand, looks like it's a bug in the example.

First example hashes second input with outPoint ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a. I reproduced hash calculation, no problems here but the example then provides resulted signed transaction where the second input with outPoint ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a is empty and instead there is signature for first input(?):


Is this really a bug in the example or I miss something?

As far as I understand older clients see SegWit transactions as zero input/one output transactions due TX format.

Awesome! I'll try to implement SegWit in my client.

Now segwit makes sense for me, thank you! One more minor question - do I understand correctly that you can fit only more transactions what use segwit addresses, and in case all clients would keep using addresses starting with 1 then the block size limit stays effectively same as it was before softfork?

pebwindkraft is right, it became too personal, I'm sorry about that.

However, there is still a common confusion about SegWit - since blocks are the same and still store all the info necessary to validate transactions, then why does it help to make blocks smaller/fit more transactions? Obviously it's related to the witness data in TX which seems to give ability to reuse some information somehow but as the thread author mentioned it's hard to see how does it do that.

nullius, it is very silly of you to think that you are the smartest and if you cannot understand some things then nobody can.

That’s an idiotic non-argument.  Tell me, Valle, if you understand the following technologies which you use every day; I guarantee that you will get zero for seven here:

0. The transistor, in its present-day integrated-circuit implementations measured in nanometers
What exactly you don't understand in transistors? It's a school basics, isn't it? Nanometer size transistors are basically same as larger ones but takes less current.

1. Lasers
Physics, like schools grade 9. Simple quantum physics/chemistry what can be explained easily in terms or resonance and basic electron levels.

2. The Global Positioning System (GPS)
This is bit trickier to understand because of relativistic effectsm however most people supposed to understand it in high school physics.

3. The secp256k1 elliptic curve cryptography algorithm used in the “original Bitcoin”, and used now
I'm author of alternative bitcoin client (android paper wallet). I do understand EC.

4. The past two decades of research in TCP congestion control algorithms
Yes... I have a my own TCP-IP implementation to understand it.

5. The metallurgy and materials science used to produce modern steels (hint: much different from steels produced 50 years ago!)
I've been studying in Bauman state university for few years in metallurgy major (dropped it, too boring)

6. The virtual memory management code in your operating system’s kernel
Approximately.

The technologies I named above are much more difficult to understand than Segwit (!).

Cool. It means it's very easy to understand where extended blocks data is stored, right?

The original bitcoin was plain and simple - there are blocks, there are transactions in the blocks, that's it. Now there is SegWit and looks like no one understands what does it mean. If all TX info is still in blocks, what was the point of segwit if transactions are still there. If the TX information is outside of the blocks from now on where is the rest?

"You are dumb and don't understand and it's okay" is not an answer - it means that you have no idea what's actually going on.