If you are looking for the math related to Bitcoin Secp256k1, it is a curve over a prime field (Fp).  The equivalent section would be 3.2.

For any finite field all values must be one of the finite values within the field.  For a F2m field the range of possible values are the natural numbers [1, 2^m-1].  So a negative number is never a valid number as it is outside the finite field.  While curves over real numbers can have an infinite number of points, curves over finite fields have a specific finite (but usually in cryptography very very large) number of values.

Well the pool operator decided to include the txn not the individual miners.  Miners have a right to use another pool.  If they agree with the decision to include this txn well they obviously wouldn't change pools would they.  However if they don't agree with that stupid decision then they are free to use a pool they find more responsible.

That is the whole point isn't it.  Most of the dust in the UTXO (forget the blockchain the critical resource is the UTXO) is from BEFORE the dust limits.  Since the dust limits were put in place most miners intentionally DO NOT include these dust outputs because they are unspendable and they will bloat the UTXO and increase the cost of all nodes forever.  So it is thinking about the future.  Miners who don't want to see the UTXO bloated IN THE FUTURE should probably choose another pool.  Right?

I think you misunderstand.   All linux "nodes" don't need to run the same linux kernel.  Nothing bad happens if they run different versions or even completely incompatible linux kernels.   All bitcoin nodes, must at all times, run "bitcoin kernels" (the core protocol) with identical outputs to any input.  If some nodes decide chain A is the longest valid chain, and some nodes decide chain B is the longest valid chain well that would be a billion dollar problem.  Any deviation no matter how small would cause a catastrophic fork in the network.

What actually makes large scale open source development in bitcoin land difficult is the "bitcoin-core" isn't just the "kernel", it isn't even just a node, it isn't even just a node and wallet.  It is the kernel, node, wallet, and and RPC server rolled into this single tightly coupled (never a good idea in software development) unified blob of dense code.   Now I am going so say something very heretical to the followers of the Church of Latter Day Satoshis, Satoshi wasn't a very good software developer (or cryptographer).   <Pause to collect your thoughts>.  He was a brilliant "idea guy".  Bitcoin as a concept was some amazing out of the box thinking and truly innovative.  The nuts and bolts of the first client however were a complete mess.   A lot of his early decisions have really hampered current day developers.  The developers can't easily make breaking changes and they need to ensure all future versions of the software are perfectly compatible with older versions of the software.  

The Linux equivalent would be if Linux didn't have a kernel and a series of packages and instead it was simply a multi GB single blob of code.  There was one repository and you had to use it all or use none of it.  If a single update on some package you weren't even using was updated well you had to download and install the new unified Linux software or remain out of date.  If the change was a breaking change you were required to upgrade or your server would be forked off the real internet.  I think you can how that might keep the Linux development team small and centralized.  That is how Bitcoin exists today.  Don't blame the current devs, just take a look at Satoshi's first client and you can see where that foundation was built.  The reality is the core protocol is never going to have more than a couple dozen developers.  The concepts are very difficult.  Most people (myself included) simply lack the competencies to do that kind of work.  The good news is you probably wouldn't need more than a couple dozen core developers if "core" actually meant the "core protocol" not "the core protocol, and a particular implementation a full node, an a particular implementation of a desktop wallet which uses that full node, and a particular implementation of an RPC server which allows direct integration at the node level".  What the core team could use is probably another couple hundred dedicated testers though.  If you are complaining about Bitcoin development and never run testnet for release candidate versions of clients well you have no room to complain.  

If the core protocol (the kernel if you will) was separated from the other functionality and developed as a smaller independent project it would be more manageable for a small dedicated core team.  This would be much like most "linux developers" aren't working on the linux kernel they are working on packages which rely on the linux kernel.  Today if you want to build a wallet you have three choices.  

The first would be to fork bitcoin-core and then keep it up to date until the end of time integrating all the changes to the mainline bitcoin-core; if you ever stop updating it then eventually it will be forked off the main network.  Also make sure that you all your future changes don't break compatibility with the mainline client.   

The second option would be to build a wallet front end which integrates with "bitcoin-core" node via RPC. Sadly some core functionality is missing so you this is less than optimal.  You will probably end up reimplementing a lot of low level functionality (like maintaining the UTXO) simply because what you need isn't available via the RPC calls.  This is arguably the safest option as the most it is the low level communications between nodes which need to be perfectly compatible and you would still be using bitcoin-core for that. 

The third option would be to build the core protocol, node, and wallet functionality from scratch.  Sounds easy but now make sure it is bit for bit compatible with bitcoin-core including handling of a million possible edge case scenarios (some of which haven't even occurred yet and the core team may not even be aware of).  Also make sure you re-implement all the bugs, weird design choices, and issues with third party packages (openssl encoding bugs, etc).  Have fun as not all of these are even well documented.   You should be a solid proponent of test driven development.   

Obviously none of those options are optimal.   However if you could just compile the bitcoin-kernel and consume that in your wallet or other bitcoin related service that would be better right?  It would be similar to how redhat consumes the linux kernel in their operating system.  Well that option requires breaking the "bitcoin-core" into components so the core protocol is an independent project.   It is a huge undertaking to decouple the kernel, node, wallet, and RPC server that Satoshi smashed together into a single unified blob of code, into separate projects which are still perfectly compatible with existing nodes.  That process has been painstakingly going on for years now and will probably take many years more.

As pointed out dust is allowed.  That miner just massively bloated the UTXO and those outputs will very likely never be spent.  The protocol tries to make this difficult by making dust non-standard and it assumes that miners are at least moderately intelligent.  Miners have to parse the UTXO to verify txn so including this dusty garbage only makes their future work more difficult.  In a logical world with rational miners wouldn't be cutting their own throat.

You may want to ask bcpool.io why they included this txn knowing that nobody will ever use those outputs and thus they will bloat the UTXO (increasing memory pressure for every node both now and in the future) probably for perpetuity.  Are they malicious or are they just ignorant and still feel competent enough to run a pool?

If you don't like this then really there are only two things you can do:
a) if you are a miner, then boycott bcpool.io as they are either idiots of malicious.  If they have no hashpower they can't mine any more stupid txns.
b) Push to make txn with outputs below the dust limit invalid.  This would be a hard fork but it could be done.  One option would be to have a lower threshold for valid.  i.e. min fee is 10,000 satoshis, dust limit is 5,430 sat, valid limit is 543 sat (1/10th dust limit).

This is about RPC.  There would be no point to bind RPC to a random port.  The question is should it be responding to requests from ip addresses which aren't part of the rpcallow (which by default is 127.0.0.1).  It doesn't give access but it does respond with an error message which is not optimal.  From a network security standpoint no information leakage is optimal.  Most firewalls don't even respond that a port is closed, they just don't respond period (by dropping the offending packets).  This gives the attacker less information.   If bitcoind rpc is only allowed to "talk" to 127.0.0.1 then it should just drop packets from any other ip address rather than respond externally with an error.

Two words: "prior art"
https://en.wikipedia.org/wiki/Prior_art

Just wait until one of your "buyers" ships back a brick in a box (delivery confirmation of course).  PayPal will gladly give him a full refund.  If you haven't gone bankrupt doing what you are doing on ebay well your lucky.  If you keep doing it, well it is only a matter of time.

What makes you think they don't know EXACTLY what they are doing.  They are getting to use ten thousand dollar rigs for a couple week free while they rapidly depreciate.  You assume the buyer is an idiot, it is far more likely this was all premeditated.  The "dumb buyer" is simply an act to get PayPal to rubber stamp the dispute.   

Here you go:
https://bitcointalk.org/index.php?topic=575142.0

Even has nuget package manager support.

There is a relationship between memory and connections but it is not linear and I doubt the memory requirements between a node with 20 connections and 5 connections is significant.  It is more likely that if you are constrained to a preset amount of memory then someday you won't be able to run a node with even a single connection.  I believe there is a thread about running a node on a VPS.  I want to say 1GB is sufficient for linux and bitcoind having dozens of connections.   Maybe someone else can provide some details.  Honestly I don't like the idea of a node on a VPS and RAM is cheap on dedicated servers so I haven't had to look too hard.

The larger issue is bandwidth.  Due to luck of the draw (you get 8 peers who are bootstrapping on high bandwidth connections) it is possible for the bandwidth requirements to be insane.  Right now your only option is a third party tool to keep it in line.

Good point. Honestly I never noticed because I always configure my firewalls as closed by default and only explicitly open ports as needed.   Your right the port should appear closed (or actually not respond at all).  If you have the skills make it so and put it into a pull request.

It can't be changed without modifying the source.  I don't believe any such patch exists.   Honestly it probably isn't worth the effort.   The network collectively has a relatively large number of available inbound ports.  There are so many right now that most nodes don't ever reach their cap (125 by default).   So for someone which sets a number of connections below eight and wants to make some of those outbound you are talking what maybe 1 to 4 potential slots?  It isn't going to much a material difference. 

You really shouldn't be running with less than eight peers. If you need to control bandwidth then (until bitcoin core supports that) you should use a third party tool rather than run less than eight nodes.   Honestly eight is the bare minimum for optimal security you want to be well connected (dozens if not hundreds of connections).   With only a few connections an isolation attack become a more feasible scenario.

server=1 doesn't override rpcallowip settings.  server=1 has no effect on bitcoind at all.  It is only used by bitcoin-qt to allow rpc calls against that application.    There is no need for an rpcdisallow setting because by default all remote addresses are blocked unless explicitly added via rpcallow.  

I believe the remote port scan is just showing access through the firewall.  It doesn't mean that bitcoind is responding (or even will respond).  

To demonstrate I shutdown bitcoind and manually punched a hole in the firewall.  nmap shows

Have you tried executing an RPC command remotely to verify that you can in fact reach bitcoind from a remote IP address.  My guess is you will not get a response from bitcoind from the remote ip address but will from the local machine.  If you want added security against a misconfiguration then explicitly close the port in the firewall.

https://blockchain.info/tx/87d8ed6aae8ad82b01e2b9d7d7ca21e55e83e8fa2ae587892f12b06d3a12253c


It has an empty/null PkScript ("output script").  Would a ScriptSig ("input signature") of just OP_TRUE lead to a valid input?
Also is it still valid to create outputs with zero value (other than OP_RETURN)?

On an unrelated issue.  There are some unspendable but still valid outputs in the UTXO which the library does not seem to handle properly.  The constructor for the Script class should probably check for cases where there is a OP_PUSHDATA1, OP_PUSHDATA2, or OP_PUSHDATA4 and insufficient bytes to complete the push. A good test case is TxID  ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767 as it is a complete mess.

For example index 4 has a PkScript (in hex) of 0x4d.  Just an OP_PUSHDATA2 with no data following.  This code runs infinitely


Yeah it would have been nice if since the genesis blocks invalid pushes produced invalid txns and thus this txn would never have made it into a block.  I haven't had a chance to take a close look but I believe the issue is in Op.ReadData().

Yeah I got it working like that but I found it easier to modify BitcoinExtKey and BitcoinExtPubKey to have the Neuter and Derive methods to avoid excess swapping between types.  Also I think it would be more clear if the "Key" property in BitcoinExtKey (and "PubKey" in BitcoinExtPubKey) were named ExtKey and ExtPubKey as they do refer to the Extended Key and ExtPubKey.    Otherwise the accessor for the actual Key or PubKey becomes bitcoinExtKey.Key.Key and bitcoinExtPubKey.PubKey.PubKey.

Correct.  It would be roughly 70 MB depending on the specific format used. The raw script and native multisig claims are a rounding error and won't significantly affect the size of the snapshot. There are ~3 million claims so the size will depend on the size of the P2SH and P2PkH claim records.  At a minimum this would be 20 bytes for the identifier plus 2 to 3 bytes avg (varint) to represent the value.  At most it would be 29 bytes per record (1 byte for type, 20 byte identifier, 8 bytes for value).  

One final optimization option would be to refactor all the native multisig outputs to their P2SH equivalents.  Users could still make claims in a trust free manner but the original scripts should probably be retained in a separate file (probably along with all other refactored outputs).  The refactor file wouldn't be needed by clients but it would be useful for web services which assist users in identifying if they have a claim and what steps they need to take to redeem that claim.

For the record here are the only "valid" unspent outputs which are still raw scripts.  This just means I haven't yet been able to provably show them as unspendable or refactor them to either a Pay2PubKeyHash or Native-Multisig claims.  It probably is possible to reduce this list of exceptions further.


To refactor valid but not non-standard outputs and to remove invalid outputs I first reduced the raw scripts in the UTXO to a set of templates.  Then updated the parser to handle these templates.  The remaining raw script outputs are one of the following templates which the parser handles as "unknown" and keeps as a raw script.





Some of these outputs are "insecure" in that once the true owner tries to spend them (or sign a claim), anyone else could modify the output and steal the coins and/or claim.  One example is  af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d:0.  The output is encumbered only by a hash (no signature required).  The ScriptSig needed to produce a valid txn is thus just some value which when hashed produces the hash value in the PkScript (output script).  The problem is that when the owner attempts to spend those outputs any other node (including a miner) could modify the txn substituting their own output instead.  Since the required input is just a value with no signature there is no way to prevent this (other than trusting a miner in secret).  I am not exactly sure how they should be handled but I am leaning towards truncating them for security reasons.


A large portion of the sub dust txns (especially the 1 satoshi variety) are spam from Satoshi's Dice.  The service used a 1 satoshi (effectively unspendable) output to notify betters of a failed bet.  They were a significant reason for the introduction of the dust output rules.  At one time the 1 satoshi outputs represented almost half of the UTXO.   Actual spendable outputs tend to grow rather slowly so without the dust rules it is entirely possible at some point the overwhelming majority of the UTXO would have been dust spam.  Despite the controversy at the time the dust rules are both logical (what purpose is there in creating outputs which are marked as spendable, stored by all nodes forever, and yet are uneconomical to spend) and necessary to prevent the UTXO from becoming utterly unmanageable.

If you are using SSS then I would share the private key directly.  For added security one or more custodians could then encrypt their share.

SSS can be complex to implement.  If you are looking for a simpler solution you could just XOR two or more "subkeys".  This provides no direct redundancy but you could create duplicates for partial redudnacy (i.e. A, A, B, B and you need at least one A and one B to create the full key).   Still at this point with multisig tools getting better personally I would just create two or more BIP38 addresses.

Then create a single P2SH address using those BIP38 addresses and fund that.

b-money didn't "solve" the byzantine general problem (prevent double spends) in any practical manner.  The first proposal requires that all nodes have unjammable perfect and synchronous communication with all other nodes.  This would be more analogous to Bitcoin only having 0-confirm txns.  If all Bitcoin nodes have synchronous perfect and unjammable communication with every single other node on the planet then double spends of even unconfirmed txns would not be possible.  As soon as a txn by one node the rest of the network would know about it and would reject any txn which spent the same coins forever.  It solves it in theory but is utterly unworkable even on a scale of hundreds of nodes much less millions.  As the original proposal was unworkable there was a second proposal which used a small number of servers in constant communication with all other servers to reach consensus on the validity of txns.  Users would submit txns and then query servers on the acceptance of the txn.  This would be similar (but with a lower trust level) than SPV clients in the Bitcoin network.  The use of "semi-trusted" servers makes the second proposal practical but it isn't decentralized or trustless.  It is closer to the security model used by ripple, where a few elite "super peers" act as guardians of the network.  If you can trust the super-peers well you can trust the currency.

The major innovation by Bitcoin was the use of blocks to form a timestamping mechanism to (partially*) solve the byzantine general problem.  This allows trustless verification of txns by all (full) nodes.  Bitcoin wasn't the first to use the concept of PoW but it was the first decentralized currency to use PoW as a solution for the byzantine general problem.  In b-money, the PoW was limited to the creation of new coins.  Beyond controlling the creation of money it wasn't used to secure the network.   Bitcoin combined the timestamping of txns with the creation of money in the form of solving blocks.  Doing so could be seen as a secondary (and very practical) form of innovation in that is solved a second problem as well.  There is a chicken and egg problem associated with how to pay for the security of the network during the bootstrapping phase.  By giving miners a subsidy in the form of newly minted coins the minting rate is controlled and the security of the network is subsidized to allow it to grow securely until such time that txn fees can allow the network to pay for itself. 

That being said it is very likely that Satoshi was aware of b-cash and was influenced by it to some degree when designing Bitcoin.


* Partially in the sense that the security model requires an attack to not have a majority of the computing power.

It would be trivial to add a "cancel" button to the bitcoin-core client (or any client) but it would be equally pointless.   Remember bitcoin is a network of nodes.  Sure you can change what your node does (i.e. forget a txn you created exists so you can double spend it) but you can't change what OTHER nodes do.

So you make txn A and it propagates the network.  Some % of other nodes (0% to 100%) accept and relay that txn.   Now you "cancel" txn A locally and create txn B.   For every node which knows of txn A they will simply reject B because it is a double spend of A.   Now if A has some issue that means it won't be included in a block (fee, txn size, dust, etc) then eventually all nodes will forget about A (drop it from the memory pool) IF you have deleted it locally.  If you have not deleted it locally your node will periodically rebroadcast it to ensure the network NEVER forgets about it permanently.  Once some nodes forget about A you can broadcast B and it may be included in a block first.  Once all nodes forget about A then it is as if "A" never occurred and B will propagate the entire network.

The simple version if bitcoin is an association of independent nodes.  You can control what your node does but you can't control what other nodes do.  It is very likely any "cancel" button could be very confusing to the user.  The user could "cancel" A and then A is still confirmed.  The user could "cancel" A and then broadcast B but no nodes (including the recipient) can see B.  Worse if B is not a double spend of A then the user could cancel "A" and then both A & B end up confirmed (double payment).

A SAR is just a report.  You make the transaction, and financial institution(s) files the report(s).  No financial institution has police powers.  They don't have the authority to seize suspected funds.  That is the job of law enforcement and it requires due process not suspicion.  If law enforcement is filing warrants to have your assets seized as part of a criminal investigation a SAR or CTR is the least of your worries.