Joseph Poon via bitcoin-dev writes:
> Ideally, a 3rd-party can be handed a transaction which can encompass all
> prior states in a compact way. For currently-designed Segregated Witness
> transactions, this requires storing all previous signatures, which can
> become very costly if individuals to
Better late than never, I should correct things here. In the future it
would probably be more productive to open an issue. Otherwise there is
no mechanism for someone to take ownership of a response.
On Sun, Aug 30, 2015 at 7:45 PM, Kristov Atlas via bitcoin-dev
wrote:
>> 1. Does your applic
On Mon, Feb 29, 2016 at 10:58 AM, Mats Jerratsch wrote:
> This is actually very useful for LN too, see relevant discussion here
>
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html
>
Is there much demand for trying to code up a patch to the reference
client? I
One of the proposals was to build the UTXO set backwards. You start from
the newest block and work backwards.
The database contains UTXOs (unspent transaction outputs) and "UFTXI"
(unfunded transaction inputs).
The procedure would be
For each transaction (last to first ordering)
For each ou
This is actually very useful for LN too, see relevant discussion here
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html
2016-02-12 11:05 GMT+01:00 Tier Nolan via bitcoin-dev
:
> On Fri, Feb 12, 2016 at 5:02 AM, wrote:
>>
>> Seems it could be done without any new op
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi
I’ve been thinking around a solution to reduce nodes bootstrap time
(IBD) as well as a way to reduce the amount of bandwidth/network usage
per node.
Not sure if this idea was/is already discussed, haven’t found anything
in a quick research.
==T
