Guido Dassori [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-08-28 to 2021-03-24
💬 Posted a total of 2 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:30:43

- reply

📅 Original date posted:2021-03-24
📝 Original message:Hello Jeremy,
I find this a very interesting idea :-)
Actually I implemented something similar a bit ago in a POC, available on
GH since a while: https://github.com/gdassori/btc-bargain
At this very moment we're working to make it production ready and cut our
transaction fees (we run a 2-on-3 wallet with buy\sell features) down to
~5%.
Guido
https://twitter.com/khs9ne
Il giorno mer 17 mar 2021 alle ore 07:30 Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> ha scritto:
> ZmnSCPxj,
>
> The chief reason to use SIGHASH_NONE (or SIGHASH_SINGLE for partial funds
> delegations) is to make it so that the delegator can dynamically choose
> things like a change output. Otherwise you need to know exactly what you
> want beforehand.
>
> I'd note that you can also achieve a decent amount of scripting capability
> for fully pre-signed transactions using layered encryption. E.g., given
> script Checksig(Alice) and Checksig(Bob), you can delegate to
> 2 of CheckMulti(Carol, Dave, Eve) by (for example) encrypting either a
> presigned txn or the actual sk's themselves with enc(Carol, enc(Dave, m)),
> enc(Carol, enc(Eve, m)), enc(Dave, enc(Eve, m)). This allows you to
> post-hoc delegate a presigned (or the keys -- which may or may not be safe
> if they are from a HD wallet mind you). You can also do a variant of
> timelock encryption by encrypting m using a verifiable delay function (this
> actually permits a new kind of relative lock, depending on where you layer
> the VDF enc, which would be N seconds from when the two parties agree to
> decrypt). The general protocol can also be optimized by giving Carol
> enc(Dave, m) and enc(Eve) but then you have to have a confidential channel
> to each delegate. You can also do a ZKCP type thing if you prove that a txn
> matching a specific format is encrypted with the preimage to a hash.
> There's a lot you can do as improvement on simple "hand the key" -- this
> sounds kinda similar to scriptless scripts?
>
> W.r.t. privacy, it certainly is a hit. But I think in situations where
> privacy is a goal, then the delegation can contact the original signer and
> ask to cooperate. However in some circumstances that won't be viable given
> access to keys or whatnot. I would suggest in these cases that you can do a
> hybrid: delegate to a script and provide a default sighash_all txn, and a
> modifiable sighash_none/single. Then the delegates can decide what is best
> to use and optimistically get the originals to sign off.
>
> Interestingly, there is a subset of cases where it is desirable to have
> privacy *from the original script holder*. Conceivably the tx does need to
> be public at some point, but for interest, once delegated to from S to S',
> S' could show a signature covering a txn hash from S', and request that S
> sign it. S' can reveal partial information -- e.g., which inputs are being
> spent, but not which outputs are being created. Maybe not super useful, but
> it is interesting to note of course.
>
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Jeremy,
>>
>> Thank you.
>>
>> Assuming only keys, an easier way of delegating would be simply to give a
>> copy of the privkey outright to the delegatee.
>>
>> However, an advantage of this technique you described is that the
>> delegator can impose additional restrictions that are programmable via any
>> SCRIPT, an ability that merely handing over the privkey cannot do.
>> Thus the technique has an ability that mere handover cannot achieve.
>>
>> If the delegatee is a known single entity, and S is simply the delegatee
>> key plus some additional restrictions, it may be possible to sign with
>> `SIGHASH_ALL` a transaction that spends A and D, and outputs to a singlesig
>> of the delegatee key.
>> This would avoid the use of `SIGHASH_NONE`, for a mild improvement in
>> privacy.
>> The output would still allow the delegatee to dispose of the funds by its
>> unilateral decision subject to the fulfillment of the script S (at the cost
>> of yet another transaction).
>> On the other hand, if S is unusual enough, the enhanced privacy may be
>> moot (the S already marks the transaction as unusual), so this variation
>> has little value.
>>
>> In terms of offchain technology, if the delegator remains online, the
>> delegatee may present a witness satisfying S to the delegator, and ask the
>> delegator to provide an alternate transaction that spends A directly
>> without spending D and outputs to whatever the delegatee wants.
>> The delegator cannot refuse since the delegatee can always use the
>> `SIGHASH_NONE` signature and spend to whatever it decides provided it can
>> present a witness satisfying S.
>> This is basically a typical "close transaction" for layer 2 technology.
>> On the other hand, one generalized use-case for delegation would be if
>> the delegator suspects it may not be online or able to sign with the
>> delegator key, so this variation has reduced value as well.
>>
>> Regards,
>> ZmnSCPxj
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210324/1ba36a44/attachment.html>

2023-06-07 18:14:12

- reply

📅 Original date posted:2018-08-28
📝 Original message:Hi Sumit,
There's no protocol api to fetch a single transaction over the p2p network.
You can query peers for mempool transactions, but once there are into a
block, no way to obtain them without fetching the entire block.
Also, you may want to take a look to spruned (
https://github.com/gdassori/spruned), it uses both the electrum & the p2p
network to do the same job you are researching on. It serves the data by
emulating some of the bitcoind rpc api, to be suitable by bitcoind backed
applications.
Guido
Il giorno mar 28 ago 2018 alle ore 19:41 Blockchain Group via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> ha scritto:
> Thanks, I'll check it out.
>
> On Tue, Aug 28, 2018, 9:17 PM Matias Alejo Garcia <ematiu at gmail.com>
> wrote:
>
>> Hi Sumit,
>>
>> Take a look at https://github.com/bitpay/bitcore/tree/v8.0.0, it is a
>> bitcoin indexing API server, with several modules, like a block explorer, a
>> wallet module, etc. It is built using Node.js.
>>
>> matías
>>
>> On Tue, Aug 28, 2018 at 12:43 PM Joseph Gleason ⑈ via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> For what it is worth, electrum has a lot or possibly all of what you are
>>> talking about since the electrum servers are designed to quickly answer the
>>> queries of light clients. So right now, you could sync up an electrum
>>> server or use an existing public one and send queries to it with json-rpc.
>>>
>>>
>>> https://github.com/kyuupichan/electrumx/blob/master/docs/protocol-methods.rst
>>>
>>>
>>> On Tue, Aug 28, 2018 at 5:36 AM Blockchain Group via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I am C++ & Node.js developer. I want to propose making a new Bitcoin
>>>> API that supports fast quering of Bitcoin blocks and transactions without
>>>> the need for syncing with all previous nodes.
>>>>
>>>> In a typical case where I want to build a full fleged Bitcoin explorer
>>>> cum wallet system on my end with external APIs, I need to sync my node and
>>>> then query for the information I need to show separately. I am proposing a
>>>> unified method of finding/quering the blockchain data with a standardized
>>>> template containing minimal information about the actual mined block or
>>>> transaction yet satify the need of what I want to query.
>>>>
>>>> I am working on making a template and a support mechanism on Node.js. I
>>>> want to propose it as an improvement (BIP). It will be a great help to
>>>> future web developers who want to make something similar.
>>>>
>>>> Thanks
>>>> Sumit Lahiri.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> Matías Alejo Garcia
>> @ematiu
>> Roads? Where we're going, we don't need roads!
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180828/85af1390/attachment.html>

2023-06-07 18:14:12

- reply