What if transactions themselves had to have proof of work, random data so that a hash of a transaction had to contain X 0's at the start such that it takes a typical PC 6 seconds or so to create a transaction.

That would add to the cost of creating a transaction and the random data could be pruned by nodes once they confirm a block as valid. It may reduce the number of spam transactions.

As I understand it, both FlexTrans and SegWit are designed to fix the Transaction Malleability problem.

FlexTrans would require a hardfork.
SegWit does not.

With that difference acknowledged, can anyone explain why SegWit is a superior solution to FlexTrans?

As many of you know, Bitcoin Unlimited is gaining momentum with miners, roughly has 30% of the hash power presently (based on last 1000 blocks, slightly more if you only go back 144 blocks). Additionally, 8 MB block miners have a small but not negligible percentage of the hash power.

There seems to be some confusion about how the fork would take place. It actually is fairly well thought out:

https://medium.com/@ViaBTC/miner-guide-how-to-safely-hard-fork-to-bitcoin-unlimited-8ac1570dc1a8#.t7nul1uz0

There are three steps the fork.

In the first step, miners willing to mine BU blocks simply indicate their willingness to do so. Many of them that are indicating a willingness to do so are probably actually running core, they do not need to upgrade in order to send the flag and it would be expensive to update to BU only to have to revert back to core if BU fork does not happen.

It is not possible to accidentally indicate support for BU, so any miners sending the BU flag are doing so intentionally and thus indicating intent to mine bigger blocks, and that is enough right now.

If 75% of the hash power indicates support for BU consistently for an entire difficulty period (2016 blocks - typically about two weeks) then they enter step two.

For step two, users are prepared for the fork. This will take two difficulty periods (four weeks) giving ample time to get the word out letting users know they will need to run a client that accepts larger blocks. During this four week process, they must maintain 75% of the hash power or the fork does not happen.

So, from the time that 75% of the hash power indicates intent for BU to the time it actually happens is a minimum of three difficulty period, a minimum of six weeks. During that 6 week period, miners that indicate they are with the BU camp will still orphan any blocks that are larger than 1 MB unless it is part of a longer fork with 6 confirmations, and that will only happen if 51% of the total hashing power activate early, not likely to happen.

Once that phase two has passed, then miners will optionally indicate that they are willing to accept blocks larger than 1 MB and build upon them. However the actual fork will not happen until 51% of the total mining power has indicated they accept blocks larger than 1 MB.

It is possible for that to never happen. One malicious scenario is 25%+ of the current mining power indicates they are with BU but is lying. That could prevent the needed 51% of all hashing power needed for a fork to become the longest chain. I doubt that will take place, that would be a conspiracy on par with censorship of users voicing their opinions on Bitcoin related forums. Oh, wait... that's even happened to me. Well anyway I still doubt that will happen.

Once a chain with six blocks built upon a block > 1 MB exists and is the longest chain, then even BU miners who have not changed their configuration will accept it as the valid chain and the fork has taken place.

That is how it will happen. Agree with it or not, it is very well thought out and avoids activation unless there truly is miner consensus on the BU fork.

-=-=-

What does that mean for you, the end user? (and me)?

Run a BU client and whether or not it happens, we are fine. It takes 95% of miner consensus for SegWit to activate, and that clearly is incredibly unlikely to happen. Even if it does happen, we can still use Bitcoin with a BU client - just keep using traditional addresses and you don't need a SegWit capable client, but since miners getting anywhere close to 95% support of SegWit is much farther off than miners sustaining 75% support of BU - there is absolutely no benefit to running a SegWit capable client now unless you are a developer using the test network.

[AND]

This entire block debate, I have seen people on both sides accusing those on the other side of being a paid shill.

That needs to stop. Such an accusation without any evidence is extremely intellectually dishonest and is basically making the claim that no one is able to have a point of view or perspective that is different than yours of their own free conclusion. It is not a position that one can have an intelligent discussion with, because when you believe someone's motives are paid, you do not have any desire to listen to their perspective or try to see their point of view.

Me - I don't have anything specific against SegWit. I am not a fan of LN because to accept payments on LN, I must have a private key on a networked computer in order to sign the smart-contracts. That may work on an individual transaction basis but it doesn't scale well to lots of transactions every hour because it isn't secure.

I take the philosophy that every piece of software my server runs has at least one vulnerability that someone else knows how to exploit. It is thus my job to continually search for those exploits and patch them when I find them AND it is my job to minimize the damage that can be done when those holes are exploited before I have found them. The way you do that with bitcoin is by not having the private keys where there is any chance of them being stolen - that means not having them on a networked computer and that means automated signing of smart contracts needed for LN is not possible for any of my websites.

But I'm not opposed to the concept of SegWit nor am I opposed to people who do not mind taking that risk and want to use LN. Let them, I'm not their Pa - it's not my business, it's their business.

However, LN is not a solution to transaction problem for me. And right now it is not a solution to the transaction volume problem for anyone because LN does not even exist right now, it's still vaporware.

I wouldn't mind if Roger Ver sent me some free money, but neither he nor anyone else has done so, my position is my own and it is the position that I believe is in the best interest of my future use of Bitcoin and I understand that other people have different perspectives.

However it is not conductive to the debate for me to accuse any of you of taking money to have your position nor is it conductive to the debate for any of you to accuse me of taking money to have my position on the debate.

Those kind of accusations without a shred of evidence need to just plain stop.

This debate needs to be discussed, but it needs to be discussed in an intellectually honest way.

If SegWit happens and the block continues to remain at 1 MB so demand dictates an increasing TX fee for anything not SegWit, and if I were to run my own SegWit side-chain - would it be subjected to federal and state laws regarding KYC, money laundering, and permits beyond what is required to just accept a payment in an on the block transaction?

I have a suspicion it would, but I do not know the legal implications of running a side-chain, so I thought I would ask.

I'm in California but I have servers all over the US (and one in London)

EDIT - to clarify, things like LightningNetwork (or whatever it is called) are what I'm talking about - side chains that need/want SegWit in the main blockchain.

[without their SegWit solution that they control]

One of the things that attracted me to bitcoin - with credit cards, the flow of money belongs to the the wealthy and that gave them power.

With bitcoin, the flow of value was returned to the people.

I didn't have to meet the rules of a bank to open a merchant account. I didn't have to keep meeting the rules of the bank or worry about my account being closed. I didn't have to keep giving a piece of every sale to a bank. A financial institution no longer controlled the flow of money.

Now what I see happening with bitcoin, a group of people (blockstream) is trying to take over the flow of value. They are doing this by keeping the block too small for normal transactions to succeed without their SegWit solution that they control, good luck running your own SegWit solution if you are not wealthy, so people like you and me will be forced to use their off-chain accounting that they control in order to use Bitcoin.

The vision of Satoshi returned power over the flow of value back to the people where it belongs. Ordinary people, extraordinary people. Rich people, poor people. Dumb people, smart people. Conservative, liberal, socialist, libertarian. The blockchain didn't give a sh*t who we were. That is changing and Satoshi's vision is being raped.

This is not something we can let happen. We have the power to prevent, we have the power to fire core. We more than have the power, we have the responsibility to fire core.

Hi all,

I'm designing my own payment processor so I don't need to rely upon BitPay or any of the others, and so I can do some things differently and more user friendly than what they do (e.g. mark as paid as soon as the TX hits the network whether or not it is in a block as long as the value is low or the customer is several times repeat)

Anyway after a lot of searching around, it appeared to me that libbitcoin was the best solution for a backend.

I've started creating RPM packages for it for CentOS 7 and I thought I would share them. Well, not the packages themselves, but the spec files that make it easy to build the packages from source.

https://github.com/AliceWonderMiscreations/libbitcoin-RPM

Note that I am *not* a libbitcoin developer.

Right now the spec files I wrote are for the 4.x development branch of libbitcoin that should not be used in production.

The stable 3.x branch isn't finished being tagged yet. The 2.x branch is, well, old. It's stable and works but is about to be replaced with 3.x

Anyway - hope they are of use to some people, libbitcoin looks like it can do so many things that are not easy to do with bitcoin-core. Not because it is better, but rather because the design goals are different. It was rather frustrating for example to find out there is no easy way to query bitcoin-core for the value associated with an address when it isn't in a wallet, bitcoin-core is very wallet oriented but the way I'm designing my payment system doesn't use the artificial construct of a wallet.

For the libbitcoin project itself (you can install it very easily without needing RPMs, I just like RPM) - https://github.com/libbitcoin

I'm currently working on a payment system. Why not just BitPay or similar? Because some of the content sold may violate their rules, either now or in the future, I honestly don't know and don't care because while the content is not illegal, there is a good chance now or in the future BitPay (or others) will tell me I can't use their service with it. It does violate PayPal rules, and only some credit card processing companies will allow it - and then only with really high TX fee.

Anyway private addresses do not belong anywhere on the server. So the payment addresses have to be generated elsewhere (on an offline computer) and then inserted into a database the web application fetches them from.

That opens it up to the possibility of SQL injection attack - meaning a hacker could inject their own payment addresses into the database.

So to combat that, the master ECDSA key used to generate all the payment addresses is used to create a signature for each payment address.

The web application then grabs both the payment address and the signature and uses the public key from the master ECDSA to verify the payment address before it goes on the invoice for the customer to pay.

That got me thinking - why isn't something like that already part of bitcoin?

What I mean is - a payment address includes a signature as part of the bitcoin uri

The client then fetches the public key used to create the signature via DNS where it is secured by DNSSEC (similar to how DANE works with TLSA records) and then verifies the payment address is valid.

Something like that wouldn't require any changes to the bitcoin protocol itself, just client support. Clients that do not want to do it don't can just ignore the signature.

It would be a form of two-factor authentication so that the end user can verify the address they are paying to does in fact belong to the website they are making a payment to and is not hacker injected.

https://blockchain.info/tx/a262a26b64a7efb3a5dd0ff829c3512df50580515039fa214b33e89be2f07c2b

Is there a specific reason why that transaction is not confirming or is it just bad luck?

As many are aware, the OpenBSD developers forked OpenSSL 1.0.1g a few years back to create LibreSSL.

Since then they have done many security related changes. Specifically they removed SSLv2 and SSLv3 and many features they believed were not necessary in a TLS library, such as heartbeat.

Little over a year ago I created a project called LibreLAMP that initially just existed to build a modern LAMP stack for CentOS 7 but linking against LibreSSL for the TLS library. That project expanded into many others servers.

Well I have now created a second project (though it requires LibreLAMP) - and that second project aims at the complete removal of OpenSSL.

For this second project, software that links against OpenSSL but isn't already replaced in the LibreLAMP project is rebuilt against LibreSSL.

https://pure.librelamp.com/

I have successfully removed OpenSSL from my CentOS workstation and laptop and three servers I run.

Generally that project uses the same versions of software as CentOS 7 - the why is explained there. Still have a lot of packages to rebuild and I doubt I'll ever have every CentOS/EPEP package that uses OpenSSL rebuilt, but every isn't really my goal - just enough so people who want OpenSSL removed can do so.

-=-

I appreciate the OpenSSL project and since the fork, the OpenSSL project has cleaned up a lot of the code themselves.

But the version of OpenSSL in CentOS 7 is from before that fork, and is a potential security problem, hence my desire at complete removal.

CentOS 7 user. That means system python is 2.7.5

That wasn't a problem with bitcoin 0.12.x

With bitcoin 0.13.0 it isn't a problem with building but it is a problem with make qa/pull-tester/rpc-tests.py

It wants python3 - I build in mock and python3 is in EPEL so I added python34 to the BuildRequires

Now when building it can find python3 but -

Code:

+ pushd src
~/build/BUILD/bitcoin-0.13.0/src ~/build/BUILD/bitcoin-0.13.0
+ srcdir=.
+ test/bitcoin-util-test.py
+ popd
+ qa/pull-tester/rpc-tests.py -extended
~/build/BUILD/bitcoin-0.13.0
Traceback (most recent call last):
  File "/builddir/build/BUILD/bitcoin-0.13.0/qa/rpc-tests/test_framework/test_framework.py", line 144, in main
    self.setup_chain()
  File "/builddir/build/BUILD/bitcoin-0.13.0/qa/rpc-tests/test_framework/test_framework.py", line 51, in setup_chain
    initialize_chain(self.options.tmpdir, self.num_nodes)
  File "/builddir/build/BUILD/bitcoin-0.13.0/qa/rpc-tests/test_framework/util.py", line 218, in initialize_chain
    datadir=initialize_datadir("cache", i)
  File "/builddir/build/BUILD/bitcoin-0.13.0/qa/rpc-tests/test_framework/util.py", line 162, in initialize_datadir
    f.write("rpcuser=" + rpc_u + "\n")
UnicodeEncodeError: 'ascii' codec can't encode character '\U0001f4bb' in position 15: ordinal not in range(128)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/builddir/build/BUILD/bitcoin-0.13.0/qa/rpc-tests/create_cache.py", line 23, in <module>
    CreateCache().main()
  File "/builddir/build/BUILD/bitcoin-0.13.0/qa/rpc-tests/test_framework/test_framework.py", line 162, in main
    print("Unexpected exception caught during testing: " + repr(e))
UnicodeEncodeError: 'ascii' codec can't encode character '\U0001f4bb' in position 88: ordinal not in range(128)
Traceback (most recent call last):
  File "qa/pull-tester/rpc-tests.py", line 341, in <module>
    runtests()
  File "qa/pull-tester/rpc-tests.py", line 200, in runtests
    subprocess.check_output([RPC_TESTS_DIR + 'create_cache.py'] + flags)
  File "/usr/lib64/python3.4/subprocess.py", line 620, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command '['/builddir/build/BUILD/bitcoin-0.13.0/qa/rpc-tests/create_cache.py', '--srcdir=/builddir/build/BUILD/bitcoin-0.13.0/src']' returned non-zero exit status 1

I'm guessing there is some python module I'm missing but its not an import error, so I don't know.

I'm not a python guru but I thought one of the reasons Python3 was suppose to be so great is because UnicodeEncodeError would be a thing of the past. Ah well.

Anyone know what I might be missing?

Right now the chroot buildroot environment *just* has python34 (Python 3.4), probably not what most people coding pythons scripts expect.

Any suggestions appreciated, especially suggestions that work.

It's no secret to most that SMTP is not secure.

The problem is with the MTA to MX stage of message delivery.

It uses opportunistic TLS which means the MTA after sending its HELO then - if the MTA supports TLS - it will send a STARTTLS command.

The receiving MX if it supports TLS will then respond with its certificate.

TLS is not required and a lot of MX servers don't even support it.

I wrote a php class that categorizes SMTP servers into 4 categories :

1) danetls
2) validtls
3) weaktls
4) insecuretls

For danetls, I determine if the host in the address is in a DNSSEC protected zone. If it is, I then look at the MX records. If they are in a DNSSEC protected zone, I look for a sane TLSA record for port 25. If it has one, then it is danetls and communicating with that domain will either be secure or won't happen.

For validtls, if it doesn't have DANE protection but responds with a valid certificate that matches the host name and is signed by a certificate authority I trust, it is validtls. It is still trivial to MITM though.

For weaktls, I am able to make a TLS connection but the certificate is either self-signed or hostname doesn't match (common with companies that outsource to google)

For insecuretls, I am unable to make a TLS connection. It may support TLS but if it does, it is protocols / cipher suites too old for me to communicate with.

Just running the test on about 30 domains that communicate with me -

https://deviant.email/tls_functions.php (output is plain text, sent as plain text)

Rather interesting.

I submitted an issue on github.

It was closed because it was considered to be a consensus issue and not a core code issue, suggested I send the issue to dev mailing list.

I did so, it's a moderated list, and it was posted.

Several responses.

I responded to a single response - just one.

My response was rejected by the moderator.

If there is not a place for open discussion that bitcoin will fail.

Nothing in my response was antagonistic or insulting or otherwise bad behavior, but the moderator made a decision that it should not be part of the conversation - the developers did not even have the opportunity to see my response because it was never posted to the list.

That is simply not acceptable in an open project.

http://secure.newegg.com/WishList/PublicWishDetail.aspx?WishListNumber=21793274

That's a Bitcoin Payment Processor I'm building - well, almost.

I'm writing the software for it now. It will act in similar fashion as BitPay but obviously different backend, and the intent is for small (or large) businesses who do not want to be at the mercy of a third party to be able to run their own payment processing safely with redundancy (e.g. the payment processor goes down, the website can still sell stuff and know when paid)

The linked wishlist is where the private keys will be (deterministic) and will accumulate transactions to send elsewhere (e.g. an exchange or a wallet for spending)

-=-

My goal was to keep the parts under a grand and I only met that goal when stuff is on sale, but...

The case is actually intended for Media Center but it is a case that the motherboard fits and looks nice, and I never have had a problem with Lian Li cases.

The mobo / cpu / memory were chosen because ECC is a must to reduce the odds of a cosmic ray causing incorrect generation of a public key or ripemd160 hash of the public key. If that happens, the generated address will not correspond with the private key and coins sent to it are effectively destroyed. My address generating code is written and double-verifies but still, ECC memory was a must and that means server board and CPU.

I could have gone with a less expensive board, one series earlier is about $40 cheaper but lacks the USB 3 support.

The power supply, I don't trust anything but Seasonic. I've built a lot of systems. Other brands, power supply failure is somewhat common - Seasonic, they are more expensive but my experience is they very rarely ever fail.

For the HD - the list shows an Intel 480 GB but that's actually not what I will be using, I will be using a 120 GB and wait until 1 TB SSDs fall in price, then use a 1 TB for the blockchain. 120 GB is probably enough to last a few years and is cheap right now. I always use Intel SSDs.

The optical drive I actually won't be using, it's only $20 but I'll be using a USB thumb drive to install. Unless there's like a $3.00 sale on them.

The video card - unfortunately xeon processors don't have Intel HD graphics (well some might, don't know, but not the less expensive ones) so if I want my payment processor to have a GUI interface the operator can use then I need a cheap video card, and that's why that is there. It's not sold by newegg so that part has to be ordered separately because newegg only accept BTC for parts they stock and ship.

Anyway so other than the lack of optical drive and initially smaller SSD (but same series) - that's what I am building to develop and test this project of mine. Well I'm developing it on my desktop, but I'll probably do some dev on that too.

Thoughts on the build?

I love building systems, I really do.

The payment processor when done will hopefully be able to support numerous different websites. Of course US law will only allow me to use it for sites I run because I don't want to be a FinCEN registered MSB - but I will probably license the software to others who want to do the same - but this is vaporware a long way from being completed.

The server though, even if I never finish the project will be of use to me.

https://github.com/bitcoin/bitcoin/pull/7613

I'm looking forward to that

Hello,

First let me state that as a Linux user since 1998, I am not a fan of SELinux on the personal workstation. Every new release of Fedora I tried running in enforcing mode and ended up disabling it. Every new release in CentOS when I stopped using Fedora the same. With CentOS 7 - the problem came because I was using SSDs for my desktop and laptop and thus using tmpfs for /tmp to reduce the writes to the drive - and apparently SELinux doesn't work very well with /tmp on tmpfs

However if if I was running a server where a lot of financial damage could be done to me or customers from a hack, I would insist upon SELinux because it can in some circumstances save your ass from a zero day exploit that isn't even known to the OS vendor for them to try to patch.

So the bitcoind should have proper SELinux configurations so it can run on servers hardened with SELinux.

There is absolutely no documentation within bitcoin-core source on how to properly set that up.

I am not knowledgeable enough about SELinux to write such documentation but I am hoping a developer here is, because it could be important to safely deploying a node on an SELinux hardened server.

-=-

I do have some basic files that were part of the ringingliberty RPM for bitcoin and appear to have been created from templates, but I must confess I do not know if they are applicable to SELinux outside the Red Hat / Fedora world or if they really are the proper implementation.

Is this the kind of thing where a bounty for proper bitcoin related documented for SELinux could be created and contributed to in order to help motivate a knowledgeable developer to write the documentation? Maybe something for the bitcoin foundation to sponsor?

It does seem to me like it would be important for proper commercial deployment to have a proper guide to deploying bitcoind on a SELinux hardened server.

I hate advertisements.

Well I should qualify that - the way this web site does advertisements is fine, and if I see one here for something I am interested in I am very likely to click the link.

I hate advertisements that use JavaScript hovers and multimedia that auto-plays.

I don't use an advertisement blocker because I believe web sites need some way to monetize.

I do use Privacy Badger extension to FireFox because those advertisements do not have a right to track me, and that blocks quite a few, but not all.

Anyway I would gladly pay something like 25 cents an hour in micropayments to my favorite new sources etc. to read their content advertisement free. I believe Lightning Network will make that possible without bloating the blockchain with constant micropayments.

Your thoughts?

Sorry until a few years ago I just used SVN and now that using git, it is all been my projects and I haven't worried about branches.

I need to squash a pull request for bitcoin and I just am not getting the concept.

https://gist.github.com/bcherny/de24955c15430efd99f1

Code:

git checkout master
git merge --squash myBranch
git commit

How to refer to "myBranch" is what I am not comprehending.

https://github.com/AliceWonderMiscreations/bitcoin

That is myBranch - but there must be something in that article that is obvious to some but not to me to allow referring to myBranch

https://github.com/bitcoin/bitcoin/pull/7588

That is the pull request I need to squash.

With the above, I assume I am suppose to co from the bitcoin/bitcoin master branch ??

CentOS 7 with qt4

Does not build GUI unless I specify  --with-gui=qt4

from configure --help it appears it should try qt5 first and when not found try qt4 but it appears to not do that.

bitcoin-core 0.11.3 allows --with-libressl but that seems to be gone from 0.12.0.

Is there a patch somewhere to add it back in?