Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 31 2020 08:40
    tunisiano187 edited #520
  • Aug 31 2020 08:40
    tunisiano187 opened #520
  • Mar 11 2020 12:20
    Beanow closed #63
  • May 17 2019 22:57
    dgenr8 opened #519
  • May 07 2019 21:30
    dgenr8 closed #475
  • Feb 27 2019 06:47
    Quaternioneer opened #518
  • Jan 22 2019 14:49
    dgenr8 closed #433
  • Dec 18 2018 22:40

    dgenr8 on master

    Add macro THROW_UNLESS Express… Pass block time instead of head… Add function 'GetBIP135BitByNam… and 3 more (compare)

  • Dec 18 2018 22:40
    dgenr8 closed #516
  • Dec 18 2018 20:47

    dagurval on master

    [Qt] show client user agent in … [Qt] simple mempool info in deb… Added Transactions Per Second o… and 9 more (compare)

  • Dec 18 2018 20:47
    dagurval closed #517
  • Dec 18 2018 19:52
    dgenr8 synchronize #517
  • Dec 04 2018 05:16
    dgenr8 opened #517
  • Nov 30 2018 13:15
    dagurval synchronize #516
  • Nov 30 2018 12:49
    dagurval opened #516
  • Nov 30 2018 08:33

    dagurval on master

    Bump to pre-release version L Merge pull request #515 from bi… (compare)

  • Nov 30 2018 08:33
    dagurval closed #515
  • Nov 29 2018 21:00

    dgenr8 on master

    [rpc] Add 'blockstatus' to bloc… Merge pull request #513 from da… (compare)

  • Nov 29 2018 21:00
    dgenr8 closed #513
  • Nov 28 2018 18:22
    dgenr8 opened #515
Joshua Green
@joshmg
@dagurval - I think you're on to something with with your suggestion. Thank you, sir.
Tom, I think that's also a likely motivation but I'm inclined the merkle root malleability would serve as larger motivation. Regardless, both are good reasons, so thank you.
Tom Harding
@dgenr8
@joshmg btw you can find TheBlueMatt on #bitcoin-core-dev IRC
Joshua Green
@joshmg
Oh, awesome. Thanks, Tom. :)
Joshua Green
@joshmg

I'm contemplating adding a protocol message to Bitcoin Verde that is focused around helping SPV wallets sync. Currently the wallet will have the node do a lot of the heavy lifting to filter blocks--a lot of which is wasted effort since very few blocks will have relevant transactions/outputs for each wallet.

Since Bitcoin Verde indexes addresses, my first thought was to just provide a message that returns a list of "blocks of interest" based on a set of addresses. This query is very efficient for Bitcoin Verde, but non-indexing nodes can never implement this. Additionally, it greatly disregards any semblance of privacy for the wallet.

The current theory I'm toying with is creating a bloom filter for each block; the bloom filter shall contain each address in each input/output. The block's bloom filter is stored on disk and can be served along the block header during the SPV's sync.

When downloaded with the header, the SPV wallet can apply its addresses to each bloom filter for a match; if there's a match then the wallet may query the node for the merkle block.

Furthermore, if the bloom filter becomes standardized (static nonce/algorithm determining its parameters), this could also help to reduce malicious nodes' ability to omit matches to SPV--if a merkle block is returned without any matches for the address but the bloom filter matched, the SPV wallet could suspect the node is omitting matching merkle branches and query a second node. The false-positive nature of the bloom filter obviously prevents the wallet from being certain that the second node isn't also lying (since the bloom filter match could be an innocent false positive), but it at least can reduce its ability of succeeding. A standardized bloom filter parameter format also prevents a malicious node always returning a BloomFilter.MatchNone filter.

Regarding extra disk usage: assuming 500 transactions per block (on average¹), with a 0.001 false positive probability, the bloom filter is about a 900 bytes per block. At ~600k blocks, that's about 515MB for the chain's filters (+45MB for the headers).

If the SPV wallet prioritizes minimizing data usage over privacy, the SPV could send its list of addresses to to the node and then return a list of block hashes that match the on-disk filters. This would still be more efficient for the node than our current paradigm, which requires the node load each full block and apply each transaction's scripts and hashes to the filter provided by the wallet.

¹ I calculated ~500 tx/block with the following Bitcoin Verde db query: select avg(t.tx_count) from (select block_id, count(*) as tx_count from block_transactions group by block_id) as t;, which returned 486.3725.

I'd love to hear your guys' thoughts on whether this would be worth the effort or if you guys can improve on the idea. Tomorrow, I'll post this to reddit and let them rip apart the idea there for feedback too.

Joshua Green
@joshmg

There was a small error in my assumptions for calculating the bloom filter size: I only assumed 1 entry per transaction--it should really be about 3 (1 input address, 2 output addresses). With those parameters, we get a filter that is about 2.75KB, which might be pushing the network size we'd want.. but accepting more false positives (0.01 instead of 0.001) brings us to 1.75KB, so a little less than double the original estimates. 1GB in network is probably too much for most SPV wallets, I believe... But for the privacy-oriented maybe not. ...again, those not interested in privacy could rely on submitting their addresses to the node directly, and letting the node do the filter processing.

I think that concludes my napkin math.

Tom Harding
@dgenr8
@joshmg You've been busy :smile: Have you reviewed neutrino and BIP157?
Joshua Green
@joshmg
haha, yeah. :) The city of dublin (Ohio) is making a token and we're going to use SLP for them, so I've been putting a lot of time and research into SPV and getting Bitcoin Verde to support things properly.
Joshua Green
@joshmg
@dgenr8 lol, welp, it looks like 157 is mostly what I was thinking. Great minds think alike, perhaps? Thanks for pointing that out! Do you know if any nodes support this currently?
Tom Harding
@dgenr8
I'm not sure what neutrino uses for a server, shouldn't be hard to discover
Joshua Green
@joshmg
Oh jeez... you guys are like my dedicated reference node for Bitcoin Verde.
Is the intent behind deprecating XT to urge ABC to implement BIP 100? (Has ABC not done this already? I'll also admit I'm uninformed of BIP100.) Regarding your article: I do agree with the notion that multiple implementations is significantly less valuable without a distributed mining profile.
dagurval
@dagurval

Oh jeez... you guys are like my dedicated reference node for Bitcoin Verde.

It's been nice having you around :-).

Is the intent behind deprecating XT to urge ABC to implement BIP 100?

No, there is no ulterior motive. A decision to continue or not needed to be announced before the fork time.

Has ABC not done this already?

ABC does not believe in hashpower signalling

Joshua Green
@joshmg
Well, I don't know of any miners (other than my two ASICs) that are mining BV, but I'll implement BIP 100 anyway, and throw a dedication comment to XT and you guys. Thanks for having me around.
Tom Harding
@dgenr8
Thanks @joshmg! One thing is sure, Bitcoin will stay exciting :grin:
Joshua Green
@joshmg
Would anyone be willing to review my Schnorr Signature verification implementation? I only found one test in Bitcoin ABC (which passes for Bitcoin Verde), and even though I've been programming for 20 years, I wouldn't exactly call myself a crypto-algorithm guru (still... even if I was, to err is human). @dgenr8 @dagurval https://github.com/SoftwareVerde/bitcoin-verde/blob/feature/schnorr-signatures/master/src/main/java/com/softwareverde/bitcoin/secp256k1/Schnorr.java -- No obligation, especially since it's Java.
Tom Harding
@dgenr8
@joshmg I saw your spec issue. Did you check the ABC implementation? If it is not implemented correctly, does it add a vulnerability?
Joshua Green
@joshmg
@dgenr8 : Do you mean the Segwit Recovery stuff?
Tom Harding
@dgenr8
Joshua Green
@joshmg
Oh, great thought--I didn't even think about them potentially implementing it that way. My assumption is whatever EC library they're using would yell at them for the invalid operation, and at least cause their tests to fail. It's possible that it instead just creates an edge case. It's almost certainly worth a look to ensure they didn't implement it by taking negative e before multiplying it with P. Would you be interested in doing that? I can, of course, but I'm not familiar with ABC's codebase at all.
@dgenr8 ^
Tom Harding
@dgenr8
I'll give it a go
Joshua Green
@joshmg
:thumbsup:
Joshua Green
@joshmg
Oh... yeah.. they definitely negate e first before multiplying it with P, @dgenr8 ....
Pieter's original implementation specified it as Let R = sG - eP. (https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki)
And when I originally did the negation of e first, Java's EC yelled that it cannot be negative. Let me verify real quick that my memory isn't wrong.
Joshua Green
@joshmg
Yeah, BouncyCastle definitely does not allow multiplying P by a negated e.
java.lang.IllegalArgumentException: The multiplicator cannot be negative
    at org.bouncycastle.math.ec.ECPoint.multiply(Unknown Source)
    at com.softwareverde.bitcoin.secp256k1.Schnorr.verifySignature(Schnorr.java:92)
    at com.softwareverde.bitcoin.secp256k1.SchnorrTests.should_validate_bitcoin_abc_test_vector_4a(SchnorrTests.java:88)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
    at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
    at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
    at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
    at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
What are your thoughts about the ramifications of this, @dgenr8 ? I don't know enough about EC math to say if it actually makes a difference, but it definitely doesn't smell good.
Tom Harding
@dgenr8
I am even less a cryptographer than you. Tagging @andrews as this is also incorporated in BU
Joshua Green
@joshmg
So, Andrew Groot just pointed this out: https://crypto.stackexchange.com/a/31066/51716 -- So it's possible, depending on their implementation, that it's all the same.
...we think.
Joshua Green
@joshmg
I brought up the topic in the ABC Telegram group. Their code does indeed handle the negated e correctly.
Basically, that stack overflow post covers it.
Also, I don't know what he means, but Amaury said that there might be something wrong with naybc? I don't know what he means... it could be a typo.

Also, tom harding might waot to have a look at naybc, it doesn't looks like it's doing good.

@dgenr8

Tom Harding
@dgenr8
I am a pain in Amaury's ass
Joshua Green
@joshmg
lmao
I know nothing about the backstory there.
Hopefully I wasn't relaying an insult then.
Tom Harding
@dgenr8
NayBC is the name of a cheap patch on an old ABC version I released, as a protest against the BCH/BSV fork he so desperately wanted
Tom Harding
@dgenr8
The stackexchange answer seems to apply, if the "size of the group" is equal to 2^256 since that is the modulus for an underflow operation.
Joshua Green
@joshmg
Does anyone know where the Bitcoin Unlimited team communicates?
(Related: I don't believe their implementation sends the "recommended" ping message after serving a merkle block to an SPV node...)
Tom Harding
@dgenr8
bitcoinunlimited.slack.com
Joshua Green
@joshmg
Thanks, @dgenr8
How do I go about getting an invite?
Tom Harding
@dgenr8
Try contacting @sickpig_twitter here. I think he'll need an email address.
Joshua Green
@joshmg
Thanks, Tom. I'll send him a PM.